Sway 1.4 is better than 1.2, in that we always have keyboard focus
when we get a keyboard_key() event.
That however is because it doesn't send keyboard_leave() on e.g. a TTY
switch.
Still, this is good enough - foot handles this and doesn't crash. We
are also able to process input without having to refocus the window.
And, Sway master (what will become Sway 1.5) has fixed this for real -
we now get a keyboard_leave() and pointer_leave() event on a TTY
switch. And the corresponding enter events when switching back.
A button may only be mapped to a single action. Detect when the user
tried to map the same button to multiple actions and error out.
To clear a binding (for example, to free up a button from the default
bindings), one can set the action it is bound to to
`NONE` (e.g. `primary-paste=NONE`).
* New config section, "mouse-bindings", where bindings are defined on
the form "action=BTN_<name>
* pointer_button() handler now scans the bindings list instead of
hardcoding primary-paste to BTN_MIDDLE.
* The implementation handles single- double- and triple clicks in the
bindings, but there is currently no way to define anything but a
single-click binding in the configuration.
New actions defined and implemented:
* scrollback up/down
* font size up/down/reset
* spawn terminal
Break out key combo parsing to a new function,
parse_key_binding_for_action(). This function parses a string
containing one or more space separated key combo definitions on the
form (mod1+mod2+...+key), where key is a XKB key name (e.g. KP_Add).
Convert all hardcoded key bindings to configuration based
bindings. These still cannot actually be configured by the user, but
at least lives in the conf struct.
This adds initial support for defining key and mouse bindings that are
applied in different terminal modes/states.
For example, there are two arrays dealing with key and mouse bindings
in the "normal" mode. Most bindings will go here.
There's also an array for "search" mode. These bindings will be used
when the user has started a scrollback search.
In the future, there may be a model selection mode as well. Or maybe
"search" and "modal selection" will be combined into a single
"keyboard" mode. We'll see.
Since the keyboard bindings depend on the current XKB keymap,
translation from the user specified key combination string cannot be
done when loading the configuration, but must be done when we've
received a keymap from the wayland server.
We should explore if it's possible to load some kind of default keymap
just to be able to verify the validity of the key combination strings
at configuration load time, to be able to reject the configuration at
startup.
A couple of key bindings have been added as proof of concept.
Mouse bindings aren't handled at all yet, and is likely to be
re-written. For example, we can probably translate the configuration
strings at configuration load time.
Handle the CSDs and the search box the same way we handle the main
grid; when we need to redraw them, call
render_refresh_{csd,search}(). This sets a flag that is checked after
each FDM iteration. All actual rendering is done here.
This also ties the commits of the Wayland sub-surfaces to the commit
of the main surface.
The user can now configure the following:
* Whether to prefer CSDs or SSDs. But note that this is only a hint to
the compositor - it may deny our request. Furthermore, not all
compositors implement the decoration manager protocol, meaning CSDs
will be used regardless of the user configuration (GNOME/mutter
being the most prominent one).
* Title bar size and color, including transparency
* Border size and color, including transparency
Also drop support for rendering the CSDs inside the main surface.
When the user left-clicks the title-bar, we start a timer. When the
timer has elapsed, we initiate a 'move' operation.
However, if the user clicked, and then started dragging right away,
there was a very visible lag since we waited for the timeout before
starting the move.
Now, on a pointer motion event we detect a running 'move' timer, and
abort it and instead start the 'move' operation right away.
I'm not sure why I added this in the first place... our cursor doesn't
depend on keyboard focus.
Furthermore, with CSDs, we may get keyboard enter events for the CSD
surfaces, and these should definitely *not* update the xcursor
as if it was inside the main surface.
Apparently, a frame callback for the cursor surface is *never*
triggered if we get a pointer-leave event *before* the callback is
triggered. At least on Sway 1.4.
This caused the cursor being stuck, and never updating once this state
was reached.
Fix by destroying the cursor frame callback on pointer-leave.
