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.
When the client is capturing the mouse, selection can only be done by
holding done shift.
This is why a lot of selection functions are no-ops if selection isn't
currently enabled.
However, there are many cases where we actually need to modify the
selection. In particular, selection_cancel().
Thus, only check for enabled selection when we're dealing with user
input.
Bonus: this also fixes a bug where an ongoing selection were finalized
as soon as the user released shift, even if he was still holding down
the mouse button.
Before, we converted each axis event's scroll amount to an integer and
scrolled that many lines.
However, axis events are speed sensitive - very slow scrolling will
result in events with a scroll amount that is < 1.0.
For us, this meant we never scrolled a single line. You could slow
scroll all day if you wanted, and still we would never scroll a single
line.
Fix this by aggregating the scroll amount from axis events until the
scroll amount is > 1.0, and then scroll.
This enables user mappings for the left mouse button with click count
> 3
I.e. it is now possible to create custom quad-click mappings (except
we don't yet support this in footrc).
They aren't really user configurable. At least not yet.
However, with this, we now handle raw key codes just like the normal
key bindings. Meaning, e.g. ctrl+g, ctrl+a, ctrl+e etc now works while
searching with e.g. a russian layout.
