steven/beansprout-custom
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update protocol to latest version

Browse source
This commit is contained in:
Ben Buhse 2025-10-04 11:54:44 -05:00
commit b541681ca1
No known key found for this signature in database
GPG key ID: 7916ACFCD38FD0B4
1 changed files with 34 additions and 165 deletions
Download patch file Download diff file Expand all files Collapse all files

199
protocol/river-window-management-v1.xml
View file

@ -87,7 +87,7 @@ SPDX-License-Identifier: ISC
manage sequence in between, for example during interactive move/resize of manage sequence in between, for example during interactive move/resize of
windows or if a window independently changes its own dimensions. windows or if a window independently changes its own dimensions.
To summarize the main loop of this protocol is as follows: To summarize, the main loop of this protocol is as follows:
1. The server sends events indicating all changes since the last 1. The server sends events indicating all changes since the last
manage sequence followed by the manage_start event. manage sequence followed by the manage_start event.
@ -666,33 +666,30 @@ SPDX-License-Identifier: ISC
<arg name="surface" type="object" interface="wl_surface"/> <arg name="surface" type="object" interface="wl_surface"/>
</request> </request>
<event name="move_requested"> <event name="pointer_move_requested">
<description summary="the window requested interactive move"> <description summary="window requested interactive pointer move">
This event informs the window manager that the window has requested to This event informs the window manager that the window has requested to
be interactively moved using the pointer. The seat argument indicates be interactively moved using the pointer. The seat argument indicates the
the seat for the move and the serial argument identifies the input event seat for the move.
(e.g. pointer button press or touch) that started the move.
The xdg-shell protocol for example allows windows to request that an The xdg-shell protocol for example allows windows to request that an
interactive move be started, perhaps when a client-side rendered interactive move be started, perhaps when a client-side rendered
titlebar is dragged. titlebar is dragged.
The window manager may use the river_seat_v1.op_start_serial request to The window manager may use the river_seat_v1.op_start_pointer request to
interactively move the window or ignore this event entirely. interactively move the window or ignore this event entirely.
This event will be followed by a manage_start event after all other new This event will be followed by a manage_start event after all other new
state has been sent by the server. state has been sent by the server.
</description> </description>
<arg name="seat" type="object" interface="river_seat_v1"/> <arg name="seat" type="object" interface="river_seat_v1"/>
<arg name="serial" type="uint"/>
</event> </event>
<event name="resize_requested"> <event name="pointer_resize_requested">
<description summary="the window requested interactive resize"> <description summary="window requested interactive pointer resize">
This event informs the window manager that the window has requested to This event informs the window manager that the window has requested to
be interactively resized using the pointer. The seat argument indicates be interactively resized using the pointer. The seat argument indicates
the seat for the resize and the serial argument identifies the input the seat for the resize.
event (e.g. pointer button press or touch) that started the resize.
The edges argument indicates which edges the window has requested to be The edges argument indicates which edges the window has requested to be
resized from. The edges argument will never be none and will never have resized from. The edges argument will never be none and will never have
@ -702,14 +699,13 @@ SPDX-License-Identifier: ISC
interactive resize be started, perhaps when the corner of client-side interactive resize be started, perhaps when the corner of client-side
rendered decorations is dragged. rendered decorations is dragged.
The window manager may use the river_seat_v1.op_start_serial request to The window manager may use the river_seat_v1.op_start_pointer request to
interactively resize the window or ignore this event entirely. interactively resize the window or ignore this event entirely.
This event will be followed by a manage_start event after all other new This event will be followed by a manage_start event after all other new
state has been sent by the server. state has been sent by the server.
</description> </description>
<arg name="seat" type="object" interface="river_seat_v1"/> <arg name="seat" type="object" interface="river_seat_v1"/>
<arg name="serial" type="uint"/>
<arg name="edges" type="uint" enum="edges"/> <arg name="edges" type="uint" enum="edges"/>
</event> </event>
@ -1424,44 +1420,21 @@ SPDX-License-Identifier: ISC
<arg name="shell_surface" type="object" interface="river_shell_surface_v1"/> <arg name="shell_surface" type="object" interface="river_shell_surface_v1"/>
</event> </event>
<request name="op_start_serial">
<description summary="start an interactive operation with a serial">
Start an interactive seat operation with a serial from either the
river_window_v1.move_requested or river_window_v1.resize_requested
event.
During the operation, op_delta events will be sent based on input
corresponding to the provided serial (e.g. pointer or touch input).
The window manager may use this operation to implement interactive
move/resize of windows by setting the position of windows and proposing
dimensions based off of the op_delta events.
The operation continues until the pointer button, touch point or similar
corresponding to the given serial is released or the op_end request is
made and applied during a manage sequence.
This request is ignored if an operation is already in progress for a
given river_seat_v1.
This request modifies window management state and may only be made as
part of a manage sequence, see the river_window_manager_v1 description.
</description>
<arg name="serial" type="uint"/>
</request>
<request name="op_start_pointer"> <request name="op_start_pointer">
<description summary="start an interactive pointer operation"> <description summary="start an interactive pointer operation">
Start an interactive pointer operation. During the operation, op_delta Start an interactive pointer operation. During the operation, op_delta
events will be sent based on pointer input. events will be sent based on pointer input.
When all pointer buttons are released, the op_release event is sent.
The pointer operation continues until the op_end request is made during
a manage sequence and that manage sequence is finished.
The window manager may use this operation to implement interactive The window manager may use this operation to implement interactive
move/resize of windows by setting the position of windows and proposing move/resize of windows by setting the position of windows and proposing
dimensions based off of the op_delta events. dimensions based off of the op_delta events.
The pointer operation continues until the op_end request is made during This request is ignored if an operation is already in progress.
a manage sequence and that manage sequence is finished. This request is
ignored if an operation is already in progress.
This request modifies window management state and may only be made as This request modifies window management state and may only be made as
part of a manage sequence, see the river_window_manager_v1 description. part of a manage sequence, see the river_window_manager_v1 description.
@ -1472,11 +1445,29 @@ SPDX-License-Identifier: ISC
<description summary="total cumulative motion since op start"> <description summary="total cumulative motion since op start">
This event indicates the total change in position since the start of the This event indicates the total change in position since the start of the
operation of the pointer/touch point/etc. operation of the pointer/touch point/etc.
This event will be followed by a manage_start event after all other new
state has been sent by the server.
</description> </description>
<arg name="dx" type="int" summary="total change in x"/> <arg name="dx" type="int" summary="total change in x"/>
<arg name="dy" type="int" summary="total change in y"/> <arg name="dy" type="int" summary="total change in y"/>
</event> </event>
<event name="op_release">
<description summary="operation input has been released">
The input driving the current interactive operation has been released.
For a pointer op for example, all pointer buttons have been released.
Depending on the op type, op_delta events may continue to be sent until
the op is ended with the op_end request.
This event is sent at most once during an interactive operation.
This event will be followed by a manage_start event after all other new
state has been sent by the server.
</description>
</event>
<request name="op_end"> <request name="op_end">
<description summary="end an interactive operation"> <description summary="end an interactive operation">
End an interactive operation. End an interactive operation.
@ -1547,19 +1538,6 @@ SPDX-License-Identifier: ISC
<entry name="mod5" value="128"/> <entry name="mod5" value="128"/>
</enum> </enum>
<request name="get_xkb_binding">
<description summary="define a new xkbcommon key binding">
Define a key binding in terms of an xkbcommon keysym and other
configurable properties.
The new key binding is not enabled until initial configuration is
completed and the enable request is made during a manage sequence.
</description>
<arg name="id" type="new_id" interface="river_xkb_binding_v1"/>
<arg name="keysym" type="uint" summary="an xkbcommon keysym"/>
<arg name="modifiers" type="uint" enum="modifiers"/>
</request>
<request name="get_pointer_binding"> <request name="get_pointer_binding">
<description summary="define a new pointer binding"> <description summary="define a new pointer binding">
Define a pointer binding in terms of a pointer button, modifiers, and Define a pointer binding in terms of a pointer button, modifiers, and
@ -1577,115 +1555,6 @@ SPDX-License-Identifier: ISC
</request> </request>
</interface> </interface>
<interface name="river_xkb_binding_v1" version="1">
<description summary="configure a xkb key binding, receive trigger events">
This object allows the window manager to configure a xkbcommon key binding
and receive events when the key binding is triggered.
The new key binding is not enabled until the enable request is made during
a manage sequence.
Normally, all key events are sent to the surface with keyboard focus by
the compositor. Key events that trigger a key binding are not sent to the
surface with keyboard focus.
If multiple key bindings would be triggered by a single physical key event
on the compositor side, it is compositor policy which key binding(s) will
receive press/release events or if all of the matched key bindings receive
press/release events.
Key bindings might be matched by the same physical key event due to shared
keysym and modifiers. The layout override feature may also cause the same
physical key event to trigger two key bindings with different keysyms and
different layout overrides configured.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xkb binding object">
This request indicates that the client will no longer use the xkb key
binding object and that it may be safely destroyed.
</description>
</request>
<request name="set_layout_override">
<description summary="override currently active xkb layout">
Specify an xkb layout that should be used to translate key events for
the purpose of triggering this key binding irrespective of the currently
active xkb layout.
The layout argument is a 0-indexed xkbcommon layout number for the
keyboard that generated the key event.
If this request is never made, the currently active xkb layout of the
keyboard that generated the key event will be used.
This request modifies window management state and may only be made as
part of a manage sequence, see the river_window_manager_v1 description.
</description>
<arg name="layout" type="uint" summary="0-indexed xkbcommon layout"/>
</request>
<request name="enable">
<description summary="enable the key binding">
This request should be made after all initial configuration has been
completed and the window manager wishes the key binding to be able to be
triggered.
This request modifies window management state and may only be made as
part of a manage sequence, see the river_window_manager_v1 description.
</description>
</request>
<request name="disable">
<description summary="disable the key binding">
This request may be used to temporarily disable the key binding. It may
be later re-enabled with the enable request.
This request modifies window management state and may only be made as
part of a manage sequence, see the river_window_manager_v1 description.
</description>
</request>
<event name="pressed">
<description summary="the key triggering the binding has been pressed">
This event indicates that the physical key triggering the binding has
been pressed.
This event will be followed by a manage_start event after all other new
state has been sent by the server.
The compositor should wait for the manage sequence to complete before
processing further input events. This allows the window manager client
to, for example, modify key bindings and keyboard focus without racing
against future input events. The window manager should of course respond
as soon as possible as the capacity of the compositor to buffer incoming
input events is finite.
</description>
</event>
<event name="released">
<description summary="the key triggering the binding has been released">
This event indicates that the physical key triggering the binding has
been released.
Releasing the modifiers for the binding without releasing the "main"
physical key that produces the bound keysym does not trigger the release
event. This event is sent when the "main" key is released, even if the
modifiers have changed since the pressed event.
This event will be followed by a manage_start event after all other new
state has been sent by the server.
The compositor should wait for the manage sequence to complete before
processing further input events. This allows the window manager client
to, for example, modify key bindings and keyboard focus without racing
against future input events. The window manager should of course respond
as soon as possible as the capacity of the compositor to buffer incoming
input events is finite.
</description>
</event>
</interface>
<interface name="river_pointer_binding_v1" version="1"> <interface name="river_pointer_binding_v1" version="1">
<description summary="configure a pointer binding, receive trigger events"> <description summary="configure a pointer binding, receive trigger events">
This object allows the window manager to configure a pointer binding and This object allows the window manager to configure a pointer binding and