1Title: Overview of GTK input and event handling 2Slug: input-overview 3 4This chapter describes in detail how GTK handles input. If you are interested 5in what happens to translate a key press or mouse motion of the users into a 6change of a GTK widget, you should read this chapter. This knowledge will also 7be useful if you decide to implement your own widgets. 8 9## Devices and events 10 11The most basic input devices that every computer user has interacted with are 12keyboards and mice; beyond these, GTK supports touchpads, touchscreens and 13more exotic input devices such as graphics tablets. Inside GTK, every such 14input device is represented by a `GdkDevice` object. 15 16To simplify dealing with the variability between these input devices, GTK 17has a concept of logical and physical devices. The concrete physical devices that 18have many different characteristics (mice may have 2 or 3 or 8 buttons, 19keyboards have different layouts and may or may not have a separate number 20block, etc) are represented as physical devices. Each physical device is 21associated with a virtual logical device. Logical devices always come in 22pointer/keyboard pairs - you can think of such a pair as a 'seat'. 23 24GTK widgets generally deal with the logical devices, and thus can be used 25with any pointing device or keyboard. 26 27When a user interacts with an input device (e.g. moves a mouse or presses 28a key on the keyboard), GTK receives events from the windowing system. 29These are typically directed at a specific surface - for pointer events, 30the surface under the pointer (grabs complicate this), for keyboard events, 31the surface with the keyboard focus. 32 33GDK translates these raw windowing system events into `GdkEvents`. 34Typical input events are button clicks, pointer motion, key presses 35or touch events. These are all represented as `GdkEvents`, but you can 36differentiate between different events by looking at their type, using 37gdk_event_get_event_type(). 38 39Some events, such as touch events or button press-release pairs, 40are connected in to each other in an “event sequence” that 41univocally identifies events that are related to the same 42interaction. 43 44When GTK creates a `GdkSurface`, it connects to the ::event 45signal on it, which receives all of these input events. Surfaces have 46have signals and properties, e.g. to deal with window management 47related events. 48 49## Event propagation 50 51The function which initially receives input events on the GTK 52side is responsible for a number of tasks. 53 541. Find the widget which got the event. 552. Generate crossing (i.e. enter and leave) events when the focus or 56 hover location change from one widget to another. 573. Send the event to widgets. 58 59An event is propagated down and up the widget hierarchy in three phases 60towards a target widget. 61 62![Event propagation phases](capture-bubble.png) 63 64For key events, the top-level window gets a first shot at activating 65mnemonics and accelerators. If that does not consume the events, 66the target widget for event propagation is window's current focus 67widget (see gtk_window_get_focus()). 68 69For pointer events, the target widget is determined by picking 70the widget at the events coordinates (see gtk_widget_pick()). 71 72In the first phase (the “capture” phase) the event is delivered to 73each widget from the top-most (the top-level `GtkWindow` or grab widget) 74down to the target widget. 75[Event controllers](event-controllers-and-gestures) that are attached 76with %GTK_PHASE_CAPTURE get a chance to react to the event. 77 78After the “capture” phase, the widget that was intended to be the 79destination of the event will run event controllers attached to 80it with %GTK_PHASE_TARGET. This is known as the “target” phase, 81and only happens on that widget. 82 83In the last phase (the “bubble” phase), the event is delivered 84to each widget from the target to the top-most, and event 85controllers attached with %GTK_PHASE_BUBBLE are run. 86 87Events are not delivered to a widget which is insensitive or unmapped. 88 89Any time during the propagation phase, a controller may indicate 90that a received event was consumed and propagation should 91therefore be stopped. If gestures are used, this may happen 92when the gesture claims the event touch sequence (or the 93pointer events) for its own. See the “gesture states” section 94below to learn more about gestures and sequences. 95 96## Keyboard input 97 98Every `GtkWindow` maintains a single focus location (in the :focus-widget 99property). The focus widget is the target widget for key events sent to 100the window. Only widgets which have :focusable set to %TRUE can become 101the focus. Typically these are input controls such as entries or text 102fields, but e.g. buttons can take the focus too. 103 104Input widgets can be given the focus by clicking on them, but focus 105can also be moved around with certain key events (this is known as 106“keyboard navigation”). GTK reserves the Tab key to move the focus 107to the next location, and Shift-Tab to move it back to the previous 108one. In addition many containers allow “directional navigation” with 109the arrow keys. 110 111Many widgets can be “activated” to trigger and action. E.g., you can 112activate a button or switch by clicking on them, but you can also 113activate them with the keyboard, by using the Enter or Space keys. 114 115Apart from keyboard navigation, activation and directly typing into 116entries or text views, GTK widgets can use key events for activating 117“shortcuts”. Shortcuts generally act as a quick way to move the focus 118around or to activate a widget that does not currently have the focus. 119 120GTK has traditionally supported different kinds of shortcuts: 121 122- Accelerators are any other shortcuts that can be activated regardless 123 of where the focus is, and typically trigger global actions, such as 124 Ctrl-Q to quit an application. 125- Mnemonics are usually triggered using Alt as a modifier for a letter. 126 They are used in places where a label is associated with a control, 127 and are indicated by underlining the letter in the label. As a special 128 case, inside menus (i.e. inside `GtkPopoverMenu`), mnemonics can be 129 triggered without the modifier. 130- Key bindings are specific to individual widgets, such as Ctrl-C or 131 Ctrl-V in an entry copy to or paste from the clipboard. They are only 132 triggered when the widget has focus. 133 134GTK handles accelerators and mnemonics in a global scope, during the 135capture phase, and key bindings locally, during the target phase. 136 137Under the hood, all shortcuts are represented as instances of `GtkShortcut`, 138and they are managed by `GtkShortcutController`. 139 140## Text input 141 142When actual text input is needed (i.e. not just keyboard shortcuts), 143input method support can be added to a widget by connecting an input 144method context and listening to its `::commit` signal. To create a new 145input method context, use gtk_im_multicontext_new(), to provide it with 146input, use gtk_event_controller_key_set_im_context(). 147 148## Event controllers and gestures 149 150Event controllers are standalone objects that can perform 151specific actions upon received `GdkEvents`. These are tied 152to a widget, and can be told of the event propagation phase 153at which they will manage the events. 154 155Gestures are a set of specific controllers that are prepared 156to handle pointer and/or touch events, each gesture 157implementation attempts to recognize specific actions out the 158received events, notifying of the state/progress accordingly to 159let the widget react to those. On multi-touch gestures, every 160interacting touch sequence will be tracked independently. 161 162Since gestures are “simple” units, it is not uncommon to tie 163several together to perform higher level actions, grouped 164gestures handle the same event sequences simultaneously, and 165those sequences share a same state across all grouped 166gestures. Some examples of grouping may be: 167 168- A “drag” and a “swipe” gestures may want grouping. 169 The former will report events as the dragging happens, 170 the latter will tell the swipe X/Y velocities only after 171 recognition has finished. 172- Grouping a “drag” gesture with a “pan” gesture will only 173 effectively allow dragging in the panning orientation, as 174 both gestures share state. 175- If “press” and “long press” are wanted simultaneously, 176 those would need grouping. 177 178Shortcuts are handled by `GtkShortcutController`, which is 179a complex event handler that can either activate shortcuts 180itself, or propagate them to another controller, depending 181on its scope. 182 183## Gesture states 184 185Gestures have a notion of “state” for each individual touch 186sequence. When events from a touch sequence are first received, 187the touch sequence will have “none” state, this means the touch 188sequence is being handled by the gesture to possibly trigger 189actions, but the event propagation will not be stopped. 190 191When the gesture enters recognition, or at a later point in time, 192the widget may choose to claim the touch sequences (individually 193or as a group), hence stopping event propagation after the event 194is run through every gesture in that widget and propagation phase. 195Anytime this happens, the touch sequences are cancelled downwards 196the propagation chain, to let these know that no further events 197will be sent. 198 199Alternatively, or at a later point in time, the widget may choose 200to deny the touch sequences, thus letting those go through again 201in event propagation. When this happens in the capture phase, and 202if there are no other claiming gestures in the widget, 203a %GDK_TOUCH_BEGIN/%GDK_BUTTON_PRESS event will be emulated and 204propagated downwards, in order to preserve consistency. 205 206Grouped gestures always share the same state for a given touch 207sequence, so setting the state on one does transfer the state to 208the others. They also are mutually exclusive, within a widget 209where may be only one gesture group claiming a given sequence. 210If another gesture group claims later that same sequence, the 211first group will deny the sequence: 212