package oxbow

  1. Overview
  2. Docs
Dynamic window manager for the river Wayland compositor

Install 

dune-project
 Dependency

github.com Readme Edit opam file Versions (1)

Authors

  1. 3
    3L0C

Maintainers

  1. 3
    3L0C

Sources

v0.1.0.tar.gz
md5=a637acaa0e19046cd65fff733874eb97
sha512=76230cbecd7510de7a05b5d1f335915ef7b6c4aa557d8dbfd23591606618d2cfa25082d17b93f2f4b53a118d1cbf6a80e4ad51cf0f099b4921fb83d6df0c9801

doc/oxbow.river/River/Server/Xkb/Bindings/River_xkb_binding_v1/index.html

Module Bindings.River_xkb_binding_v1Source

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.

Sourcetype 'v t = ([ `River_xkb_binding_v1 ], 'v, [ `Server ]) Wayland.Proxy.t

Version 1

Sourceval released : [< `V1 | `V2 | `V3 ] t -> unit

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.

Sourceval pressed : [< `V1 | `V2 | `V3 ] t -> unit

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.

Version 2, 3

Sourceval stop_repeat : [< `V2 | `V3 ] t -> unit

Repeating should be stopped.

This event indicates that repeating should be stopped for the binding if the window manager has been repeating some action since the pressed event.

This event is generally sent when some other (possibly unbound) key is pressed after the pressed event is sent and before the released event is sent for this binding.

This event will be followed by a manage_start event after all other new state has been sent by the server.

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.