This extends the "normal" bind action enum with mouse specific
actions.
When parsing key bindings, we only check up to the last valid keyboard
binding, while mouse bindings support *both* key actions and mouse
actions.
The new actions are:
* select-begin: starts an interactive selection
* select-extend: interactively extend an existing selection
* select-word: select word under cursor
* select-word-whitespace: select word under cursor, where the only
word separating characters are whitespace characters.
The old hard-coded selection "bindings" have been converted to instead
use these actions, via default bindings added to the configuration.
This simplifies the handling of mouse and keyboard bindings.
Before, the bindings where parsed *both* when loading the
configuration, and then on every keyboard enter event. This was done
since keys require a keymap to be decoded. Something we don't have at
configuration time. The idea was that at config time, we used a
default keymap just to verify the key combo strings were valid.
The following has changed:
* The bindings in the config struct is now *one* key combo per
entry. Previously, it was one *action* per entry, and each entry
had one or more key combos.
Doing it this way makes it easier when converting the binding in the
keyboard enter event (which previously had to expand the combos
anyway).
* The bindings in the config struct no longer contains any unparsed
strings.
A key binding contains a decoded 'modifier' struct (which specifies
whether e.g. ctrl, or shift, or ctrl+shift must be pressed for the
binding to be used).
It also contains a decoded XKB keysym.
* A mouse binding in the config struct is similar to a key binding,
except it contains the button, and click count instead of the XKB
key sym.
* The modifiers in the user-specified key combo is decoded at config
time, by using the pre-defined XKB constants
XKB_MOD_NAME_<modifier>.
The result is stored in a 'modifiers' struct, which is just a
collection of booleans; one for each supported modifier.
The supported modifiers are: shift, ctrl, alt and meta/super.
* The key sym is decoded at config time using
xkb_keysym_from_name(). This call does *not* depend on a keymap.
* The mouse button is decoded at config time using a hardcoded mapping
table (just like before).
* The click count is currently hard-coded to 1.
* In the keyboard enter event, all we need to do is pre-compute the
xkb_mod_mask_t variable for each key/mouse binding, and find all the
*key codes* that map to the (already decoded) symbol.
For mouse bindings, the modifiers are the *only* reason we convert
the mouse bindings at all.
In fact, on button events, we check if the seat has a keyboard. If
not, we use the mouse bindings from the configuration directly, and
simply filter out those with a non-empty set of modifiers.
While refactoring this code, the check for LMB or RMB got changed to
LMB or "any button".
This fixes that.
It also adds a boolean 'cursor_is_on_grid', which should make the code
easier to read and understand.
Don't send mouse button escapes to a mouse grabbing client when the
cursor is outside the grid (i.e. when it is inside the margins).
Also don't do *any* kind of selection when the cursor is outside the
grid. Previously, we only checked this for selection_start(), but
e.g. double clicking would run selection_extend(), or
selection_mark_word() etc.
Previously, the selection was only updated when the mouse cursor was
inside the grid. This makes it difficult to e.g. do large selections
fast, since you often end up moving the cursor outside the grid, or
outside the terminal window even.
Now, we update the selection regardless of *where* the cursor is. This
is done by bounding the row/col we pass to 'selection_update()' to the
grid, while still setting the seat's row/col to -1 when the cursor is
outside the grid, to ensure the xcursor etc are set correctly.
Care must also be taken to *not* pass any motion events to a mouse
grabbing client, when the cursor is outside the grid.
Closes#70.
This fixes an issue where the col/row were incorrectly set to 0
instead of -1, when the mouse cursor was inside the grid margins.
This resulted in e.g. the mouse cursor having the wrong shape, and
foot incorrectly handling mouse events as if they were inside the
grid.
When enabled, the mouse cursor is hidden when the user types in the
terminal. It is un-hidden when the user moves the mouse, or when the
window loses keyboard focus.
This allows us to detect syntax errors early on, and is also more
efficient since we don't have to re-tokenize the command line every
time the binding is executed.
* Fix col/row calculation in pointer-enter event; we did not take the
margins into account.
* seat->mouse.col,row are now set to -1 if the cursor is inside the
margins. That is, col/row are only ever valid when the mouse is
actually over the grid, and not in the margins.
* Use regular 'left-ptr' mouse cursor when mouse is inside the
margins, to not make the user think he/she can start a selection.
Besides making things clearer, this also fixes a crash that occurred
if you started a selection in e.g. the right margin.
* xcursor always set for all pointers
* xcursor sometimes not updated when it should be
* mouse grabbed state wasn't per seat, but global (i.e. "does at least
one seat enable mouse grabbing")
* selection enabled state wasn't per seat
That is, only call term_kbd_focus_in() if we're the *first* seat
focusing that terminal, and only call term_kbd_focus_out() if we're
the *last* seat that focused it.
Previously, we triggered a theme reload on output changes. This is
completely wrong. We may get a new output with a scale different from
the output the pointer is actually on.
Now, we store the current scale along with the theme. We then trigger
a call to reload the xcursor theme *every* time the pointer enters a
surface. When it does, we use the current scale factor of the terminal
that owns that surface.
If the terminal covers multiple outputs, with different scale factors,
we'll use the largest scale factor. This may not be 100% correct. But
to fix that, we'd need to track which regions of a surface are mapped
on which outputs. Too complicated I say.
