Zander671/river
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

river-control: send output on success, fix issues

Browse Source 
Add an output arg to the success event on the callback. This allows for
implementing commands that return values, which are planned.

Replace the array of null terminated strings with a series of requests
each adding a single string to the args array. This is more idiomatic
wayland.

Add a seat argument to the run_command request to allow for proper
multi-seat support in the future.

Add missing destructor request.
This commit is contained in:
Isaac Freund 2020-06-15 15:07:10 +02:00
parent 5d9eb6a40a
commit e7bf1940da
No known key found for this signature in database
GPG Key ID: 86DED400DDFD7A11
1 changed files with 36 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
protocol/river-control-unstable-v1.xml
View File

@ -19,32 +19,57 @@
<interface name="zriver_control_v1" version="1">
<description summary="run compositor commands">
This interface allows clients to run compositor commands and receive a
success/failure response with a failure message if needed.
success/failure response with output or a failure message respectively.
Each command is built up in a series of add_argument requests and
executed with a run_command request. The first argument is the command
to be run.
A complete list of commands should be made available in the man page of
the compositor.
</description>
<request name="run_command">
<description summary="run a compositor command">
A complete list of commands will be found in the man page for the
compositor.
<request name="destroy" type="destructor">
<description summary="destroy the river_control object">
This request indicates that the client will not use the
river_control object any more. Objects that have been created
through this instance are not affected.
</description>
<arg name="command" type="array" summary="the command to run as a series
of null-terminated strings"/>
</request>
<request name="add_argument">
<description summary="add an argument to the current command">
Arguments are stored by the server in the order they were sent until
the run_command request is made.
</description>
<arg name="argument" type="string" summary="the argument to add"/>
</request>
<request name="run_command">
<description summary="run the current command">
Execute the command built up using the add_argument request for the
given seat.
</description>
<arg name="seat" type="object" interface="wl_seat"/>
<arg name="callback" type="new_id" interface="zriver_command_callback_v1"
summary="callback object to receive success/error events"/>
summary="callback object"/>
</request>
</interface>
<interface name="zriver_command_callback_v1" version="1">
<description summary="callback object">
This object is created by the run_command request. Exactly one of the
success or failure events will be sent.
success or failure events will be sent. This object will be destroyed
by the compositor after one of the events is sent.
</description>
<event name="success">
<description summary="command successful">
Send when the command has been successfully received and validated by
the server and will be carried out.
Sent when the command has been successfully received and executed by
the compositor. Some commands may produce output, in which case the
output argument will be a non-empty string.
</description>
<arg name="output" type="string" summary="the output of the command"/>
</event>
<event name="failure">