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
New 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.
New 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.
New 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.
Sourceval session_unlocked : [< `V1 | `V2 | `V3 | `V4 | `V5 ] t -> unit 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.
Sourceval session_locked : [< `V1 | `V2 | `V3 | `V4 | `V5 ] t -> unit 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.
Sourceval render_start : [< `V1 | `V2 | `V3 | `V4 | `V5 ] t -> unit 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.
Sourceval manage_start : [< `V1 | `V2 | `V3 | `V4 | `V5 ] t -> unit 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.
Sourceval finished : [< `V1 | `V2 | `V3 | `V4 | `V5 ] t -> unit 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.
Sourceval unavailable : [< `V1 | `V2 | `V3 | `V4 | `V5 ] t -> unit 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.
Sourceclass virtual +'a v1 : object ... end Handler for a proxy with version >= 1.
Sourceclass virtual +'a v2 : object ... end Handler for a proxy with version >= 2.
Sourceclass virtual +'a v3 : object ... end Handler for a proxy with version >= 3.
Sourceclass virtual +'a v4 : object ... end Handler for a proxy with version >= 4.
Sourceclass virtual +'a v5 : object ... end Handler for a proxy with version >= 5.