Copyright © 2015-2017 Quentin “Sardem FF7” Glidic
Copyright © 2023-2024 Anna "navi" Figueiredo Gomes
Permission to use, copy, modify, distribute, and sell this
software and its documentation for any purpose is hereby granted
without fee, provided that the above copyright notice appear in
all copies and that both that copyright notice and this permission
notice appear in supporting documentation, and that the name of
the copyright holders not be used in advertising or publicity
pertaining to distribution of the software without specific,
written prior permission. The copyright holders make no
representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied
warranty.
THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
THIS SOFTWARE.
This protocol allows clients to register "actions" as a set of triggers
and metadata, and get notified when those actions are triggered by the user.
Warning! The protocol described in this file is currently in the testing
phase. Backward compatible changes may be added together with the
corresponding interface version bump. Backward incompatible changes can
only be done by creating a new major version of the extension.
This interface is designed to allow any application to bind an action.
It is left to the compositor to determine which client will get events.
The choice can be based on policy, heuristic, user configuration, or any
other mechanism that may be relevant.
Here are some examples of dispatching choice: all applications, last
focused, user-defined preference order, latest fullscreened application.
This interface is exposed as global.
The client no longer wants to receive events for any action.
Creates a binding.
After setting the metadata on all bindings created, the client must
call ext_action_binder_v1.commit for the binding to take effect.
Commits all bindings created from this interface.
This request may be called again if new bindings are created,
already bound bindings are unaffected.
After calling bind, either the "bound" or "rejected" event is sent
for each binding created.
If no action has been set for any binding, the error "invalid_binding" is raised.
This interface defines an individual binding, allowing the client to register metadata about
the action and receive triggered events.
The client no longer wants to receive events for this binding.
Sets an arbitrary couple of a namespace and a name describing the
wanted behaviour. These two strings are not meant to be user-visible.
Some namespaces are well-known and shared by applications while each
application can have its own namespaces for internal actions.
It is possible to have the same action in several namespaces, e.g. to
allow application-specific bindings in addition to global actions.
A name must be set before attempting to commit a binding.
Attempting to send this request twice or after the binding was bound raises an already set error.
This setting is optional.
This description may be used by the compositor to render a ui for bindings.
Attempting to send this request twice or after the binding was bound raises an already_set error.
This setting is optional.
The app ID identifies the general class of applications to which
the binding belongs. The compositor can use this to select which
client will receive an event.
Attempting to send this request twice or after the binding was bound raises an already_set error.
This setting is optional.
Attempting to send this request twice or after the binding was bound raises an already_set error.
This setting is optional.
The trigger is a suggestion to the compositor, and the action should not rely
on being set to that specific trigger.
The client does not know which trigger was actually set, but when a binding is
bound, it receives from the compositor a human readable string describing the trigger,
if any, so it could show it in a ui.
The trigger format is split into two fields, what kind of device triggers it, and a
general trigger string.
As of version 1 of this protocol, the following kinds are defined:
"sym": trigger is a combo of XKB key names.
"mouse": trigger is button[1-9], mapped to their x11 values, (1=left, 2=middle, 3=right,
4=scroll up, 5=scroll down, 6=scroll left, 7=scroll right, 8=back, 9=forward).
"switch": trigger on the format switch:state, where "lid" and "tablet" are valid switches.
"gesture": trigger on the format gesture[:fingers][:direction] with the following gestures:
hold: 1-5 fingers, no direction.
swipe: 3-5 fingers, up, down, left or right.
pinch: 2-5 fingers, all above, inward, outward, clockwise, counterclockwise.
Attempting to send this request twice or after the binding was bound raises an already_set error.
Sent after the event was processed, and was bound to one or more of the actions set.
Sent after the event was processed and got rejected,
or at any time should the compositor want to remove the binding.
The compositor will send no further events after this event.
The client should destroy the object at this point.
Depending on the user configuration, an action can be either one_shot or
sustained. The client must handle all the three event types and either make
sense of them or ignore them properly.
one_shot actions are for events that don't have a defined "end", like a laptop
lid closing, or a gesture. The client should not expect to recieve a released or
ending event for that action.
sustained actions have a start and an end. after a 'pressed' event is sent, a
'released' event should eventually be sent as well.
This event is sent when actions are triggered.
If a binding would trigger both triggered and started events, the
started event must be sent first.