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.