package oxbow
Install
dune-project
Dependency
Authors
Maintainers
Sources
md5=a637acaa0e19046cd65fff733874eb97
sha512=76230cbecd7510de7a05b5d1f335915ef7b6c4aa557d8dbfd23591606618d2cfa25082d17b93f2f4b53a118d1cbf6a80e4ad51cf0f099b4921fb83d6df0c9801
doc/oxbow.river/River/Server/Window_management/River_window_manager_v1/index.html
Module Window_management.River_window_manager_v1Source
Window manager global interface.
This global interface should only be advertised to the window manager process. Only one window management client may be active at a time. The compositor should use the unavailable event if necessary to enforce this.
There are two disjoint categories of state managed by this protocol:
Window management state influences the communication between the compositor and individual windows (e.g. xdg_toplevels). Window management state includes window dimensions, fullscreen state, keyboard focus, keyboard bindings, and more.
Rendering state only affects the rendered output of the compositor and does not influence communication between the compositor and individual windows. Rendering state includes the position and rendering order of windows, shell surfaces, decoration surfaces, borders, and more.
Window management state may only be modified by the window manager as part of a manage sequence. A manage sequence is started with the manage_start event and ended with the manage_finish request. It is a protocol error to modify window management state outside of a manage sequence.
A manage sequence is always followed by at least one render sequence. A render sequence is started with the render_start event and ended with the render_finish request.
Rendering state may be modified by the window manager during a manage sequence or a render sequence. Regardless of when the rendering state is modified, it is applied with the next render_finish request. It is a protocol error to modify rendering state outside of a manage or render sequence.
The server will start a manage sequence by sending new state and the manage_start event as soon as possible whenever there is a change in state that must be communicated with the window manager.
If the window manager client needs to ensure a manage sequence is started due to a state change the compositor is not aware of, it may send the manage_dirty request.
The server will start a render sequence by sending new state and the render_start event as soon as possible whenever there is a change in window dimensions that must be communicated with the window manager. Multiple render sequences may be made consecutively without a manage sequence in between, for example if a window independently changes its own dimensions.
To summarize, the main loop of this protocol is as follows:
1. The server sends events indicating all changes since the last manage sequence followed by the manage_start event.
2. The client sends requests modifying window management state or rendering state (as defined above) followed by the manage_finish request.
3. The server sends new state to windows and waits for responses.
4. The server sends new window dimensions to the client followed by the render_start event.
5. The client sends requests modifying rendering state (as defined above) followed by the render_finish request.
6. If window dimensions change, loop back to step 4. If state that requires a manage sequence changes or if the client makes a manage_dirty request, loop back to step 1.
For the purposes of frame perfection, the server may delay rendering new state committed by the windows in step 3 until after step 5 is finished.
It is a protocol error for the client to make a manage_finish or render_finish request that violates this ordering.
Version 1, 2, 3
val seat :
([< `V1 | `V2 | `V3 | `V4 | `V5 ] as 'a) t ->
[[ `River_seat_v1 ], 'a, [ `Server ]] Wayland.Proxy.Handler.t ->
([ `River_seat_v1 ], 'a, [ `Server ]) Wayland.Proxy.tNew seat.
A new seat has been created.
This event will be followed by a manage_start event after all other new state has been sent by the server.
val output :
([< `V1 | `V2 | `V3 | `V4 | `V5 ] as 'a) t ->
[[ `River_output_v1 ], 'a, [ `Server ]] Wayland.Proxy.Handler.t ->
([ `River_output_v1 ], 'a, [ `Server ]) Wayland.Proxy.tNew output.
A new logical output has been created, perhaps due to a new physical monitor being plugged in or perhaps due to a change in configuration.
This event will be followed by river_output_v1.position and dimensions events as well as a manage_start event after all other new state has been sent by the server.
val window :
([< `V1 | `V2 | `V3 | `V4 | `V5 ] as 'a) t ->
[[ `River_window_v1 ], 'a, [ `Server ]] Wayland.Proxy.Handler.t ->
([ `River_window_v1 ], 'a, [ `Server ]) Wayland.Proxy.tNew window.
A new window has been created.
This event will be followed by a manage_start event after all other new state has been sent by the server.
The session has been unlocked.
This event indicates that the session has been unlocked.
This event will be followed by a manage_start event after all other new state has been sent by the server.
The session has been locked.
This event indicates that the session has been locked.
The window manager may wish to restrict which key bindings are available while locked or otherwise use this information.
If the session is currently locked when the river_window_manager_v1 object is created, the session_locked event will be sent in the first manage sequence.
This event will be followed by a manage_start event after all other new state has been sent by the server.
Start a render sequence.
This event indicates that the server has sent all river_window_v1.dimensions events necessary.
In response to this event, the client should make requests modifying rendering state as it chooses. Then, the client must make the render_finish request.
See the description of the river_window_manager_v1 interface for a complete overview of the manage/render sequence loop.
Start a manage sequence.
This event indicates that the server has sent events indicating all state changes since the last manage sequence.
In response to this event, the client should make requests modifying window management state as it chooses. Then, the client must make the manage_finish request.
See the description of the river_window_manager_v1 interface for a complete overview of the manage/render sequence loop.
The server has finished with the window manager.
This event indicates that the server will send no further events on this object. The client should destroy the object. See river_window_manager_v1.destroy for more information.
Window management unavailable.
This event indicates that window management is not available to the client, perhaps due to another window management client already running. The circumstances causing this event to be sent are compositor policy.
If sent, this event is guaranteed to be the first and only event sent by the server.
The server will send no further events on this object. The client should destroy this object and all objects created through this interface.
Version 4, 5
Handlers
Note: Servers will always want to use v1.