package oxbow
Install
dune-project
Dependency
Authors
Maintainers
Sources
md5=a637acaa0e19046cd65fff733874eb97
sha512=76230cbecd7510de7a05b5d1f335915ef7b6c4aa557d8dbfd23591606618d2cfa25082d17b93f2f4b53a118d1cbf6a80e4ad51cf0f099b4921fb83d6df0c9801
doc/oxbow.river/River/Obj/Window_management/C/River_window_manager_v1/index.html
Module C.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 get_shell_surface :
([< `V1 | `V2 | `V3 | `V4 | `V5 ] as 'a) t ->
[[ `River_shell_surface_v1 ], 'a, [ `Client ]] Wayland.Proxy.Handler.t ->
surface:([ `Wl_surface ], 'b, [ `Client ]) Wayland.Proxy.t ->
([ `River_shell_surface_v1 ], 'a, [ `Client ]) Wayland.Proxy.tAssign the river_shell_surface_v1 surface role.
Create a new shell surface for window manager UI and assign the river_shell_surface_v1 role to the surface.
Providing a wl_surface which already has a role or already has a buffer attached or committed is a protocol error.
Finish a render sequence.
This request indicates that the client has made all changes to rendering state it wishes to include in the current manage sequence and that the server should atomically apply and display these state changes to the user.
After sending this request, it is a protocol error for the client to make further changes to rendering state until the next manage_start or render_start event is received, whichever comes first.
See the description of the river_window_manager_v1 interface for a complete overview of the manage/render sequence loop.
Ensure a manage sequence is started.
This request ensures a manage sequence is started and that a manage_start event is sent by the server. If this request is made during an ongoing manage sequence, a new manage sequence will be started as soon as the current one is completed.
The client may want to use this request due to an internal state change that the compositor is not aware of (e.g. a dbus event) which should affect window management or rendering state.
Finish a manage sequence.
This request indicates that the client has made all changes to window management state it wishes to include in the current manage sequence and that the server should atomically send these state changes to the windows and continue with the manage sequence.
After sending this request, it is a protocol error for the client to make further changes to window management state until the next manage_start event is received.
See the description of the river_window_manager_v1 interface for a complete overview of the manage/render sequence loop.
Destroy the river_window_manager_v1 object.
This request should be called after the finished event has been received to complete destruction of the object.
If a client wishes to destroy this object it should send a river_window_manager_v1.stop request and wait for a river_window_manager_v1.finished event. Once the finished event is received it is safe to destroy this object and any other objects created through this interface.
Stop sending events.
This request indicates that the client no longer wishes to receive events on this object.
The Wayland protocol is asynchronous, which means the server may send further events until the stop request is processed. The client must wait for a river_window_manager_v1.finished event before destroying this object.
Version 4, 5
Exit the Wayland session.
End the current Wayland session and exit the compositor. All Wayland clients running in the current session, including the window manager, will be disconnected.
Window managers should only make this request if the user explicitly asks to exit the Wayland session, not for example on normal window manager termination.
Handlers
Note: Servers will always want to use v1.