package oxbow
Install
dune-project
Dependency
Authors
Maintainers
Sources
md5=a637acaa0e19046cd65fff733874eb97
sha512=76230cbecd7510de7a05b5d1f335915ef7b6c4aa557d8dbfd23591606618d2cfa25082d17b93f2f4b53a118d1cbf6a80e4ad51cf0f099b4921fb83d6df0c9801
doc/oxbow.river/River/Server/Window_management/River_pointer_binding_v1/index.html
Module Window_management.River_pointer_binding_v1Source
Configure a pointer binding, receive trigger events.
This object allows the window manager to configure a pointer binding and receive events when the binding is triggered.
The new pointer binding is not enabled until the enable request is made during a manage sequence.
Normally, all pointer button events are sent to the surface with pointer focus by the compositor. Pointer button events that trigger a pointer binding are not sent to the surface with pointer focus.
If multiple pointer bindings would be triggered by a single physical pointer event on the compositor side, it is compositor policy which pointer binding(s) will receive press/release events or if all of the matched pointer bindings receive press/release events.
Version 1, 2, 3, 4, 5
The bound pointer button has been released.
This event indicates that the pointer button triggering the binding has been released.
Releasing the modifiers for the binding without releasing the pointer button does not trigger the release event. This event is sent when the pointer button 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.
The bound pointer button has been pressed.
This event indicates that the pointer button 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.
Handlers
Note: Servers will always want to use v1.