Store a list of currently pressed buttons, and which surface they
belong to (i.e. which surface that received the press).
Then, in motion events (with a button pressed, aka drag operations),
send the event to the “original” surface (that received the press).
Also send release events to the originating surface.
This means a surface receiving a press will always receive a
corresponding release. And no one will receive a release event without
a corresponding press event.
Motion events with a button pressed will *always* use the *first*
button that was pressed. I.e. if you press a button, start dragging,
and then press another button, we keep generating motion events for
the *first* button.
As long as the mouse button was *pressed* while the pointer was inside
the grid, we want to keep reporting motion events until the button is
released.
Even when the pointer moves outside the grid (but in this case, the
reported coordinates are bounded by the grid size).
This patch also tries to improve multi-button handling (i.e. multiple
buttons pressed at the same time), and the events we report to the
client for these, in the following ways:
* Motion events now report the *initial* button. That is, if you start
a drag operation with the LEFT button, then press RIGHT (before
releasing LEFT), keep reporting LEFT in the motion events.
* Mouse release events are reported for *any* button, as long as the
pointer is *inside* the grid, *or*, the button released was the
button used to start a drag operation.
The last point is important; if we have reported a button press
followed by motion events (i.e. a drag operation), we need to report
the button release, *even* if the pointer is outside the grid.
Note that the client may receive unbalanced button press/release
events in the following ways if the user pressed one, and then a
second button *inside* the grid, then releases the *first*
button (possibly outside the grid), and finally releases the *second*
button *outside* the grid.
In this case, both buttons will report press events. The first button
will report a release event since it is the initial button in the drag
operation.
However, we don’t track the fact that the second button is being
pressed, and thus if it is released outside the grid, it wont generate
a release event.
This is done by allocating cells for the pre-edit text when receiving
the text-input::done() call, and populating them by converting the
utf-8 formatted pre-edit text to wchars.
We also convert the pre-edit cursor position to cell positions (it can
cover multiple cells).
When rendering, we simply render the pre-edit cells on-top off the
regular grid. While doing so, we also mark the underlying, “real”,
cells as dirty, to ensure they are re-rendered when the pre-edit text
is modified or removed.
Don’t require NumLock to be locked. Foot has no idea _which_ modifier
the user has mapped NumLock to, meaning we really cannot require it to
be locked.
This mode can be set by client programs with the DECSET, DECRST,
XTSAVE and XTRESTORE sequences by using 27127 as the parameter.
The sequence "\E[27;1;27~" is encoded in the same way as is done by
xterm's "modifyOtherKeys" mode. Even though xterm itself never emits
such a sequence for the Escape key, many programs already have
support for parsing this style of key sequence.
With XKB, Shift+Tab maps to XKB_KEY_ISO_Left_Tab, not
XKB_Key_Tab. Previously, we had two different lookup tables for the
two.
The tab table was correctly populated, while the ISO-left tab
wasn’t. As a result, all Shift+Tab combos (except Shift+Tab itself)
was wrong, and resulted in the same escape sequence as Shift+Tab.
Fix by using the same table for both tab and ISO-left tab.
Closes#210
When num lock override has been enabled via “CSI?1035h” (the default),
keypad is always considered to be in ‘numerical’ mode.
This affects how keypad keys are translated to escape sequences when
Num Lock is active.
The keypad has four modes:
* Num Lock off, numerical mode
* Num Lock off, application mode
* Num Lock on, numerical mode
* Num Lock on, application mode
The keymap is identical for numerical and application mode when Num
Lock is off, meaning the keypad effectively has three different modes.
In XTerm, numerical and application mode _can_ be the same, **if** the
‘numLock’ resource is set to true (the default). It is only when
‘numLock’ is false that the application mode is actually used.
This patch changes foot to do the same. We don’t expose an option, but
do implement “CSI ? 1035”.
Closes#194
When converting mouse scroll events to keyboard input (in alternate
scroll mode), we need to use seat->mouse_focus, not seat->kbd_focus.
To enable this, break out key press/release handling code to a
separate function that takes an explicit term argument. Call this
function from keyboard_key(), input_repeat() and in alternate scroll
mode.
Closes#179
* Don’t de-reference the xkb context/keymap/state if we failed to
instantiate them.
* Don’t try to send a translated utf8 key sequence if the translation
failed.
* Handle xkb_compose_state_get_utf8() and xkb_state_key_get_utf8()
returning more than 64 bytes.
This _may_ fix#171.
Handle xkb_compose_table_new_from_locale() returning NULL. When this
happens, log a warning that “dead keys” will be disabled, and make
sure to never de-reference the compose table pointer.
Closes#170
When we ‘consume’ a mouse button event (i.e. when we have a shortcut
mapped to it), the event should *not* be passed on to the client
application.
In 5f64c5c335, button handling was
refactored and unfortunately introduced a regression where we once
again started passing consumed button presses to the client
application.
Fixes#168
Trackpad scroll movements are in pixels. Foot previously “translated”
these directly to line movements (i.e. a one pixel scroll event was
translated into a one line scroll).
Now we use the line height of the terminal and correctly convert
pixels to lines.
This makes the trackpad scroll speed in foot consistent with the
scroll speed in e.g. Alacritty and Kitty.
Allow a mouse binding to match even if its click count is less than
the actual click count.
If there are multiple bindings that match, use the one with the
highest click count (that less than, or equal to the actual click
count).
Closes#146
Moving the mouse outside the grid while we have an on-going selection
now starts a timer. The interval of this timer depends on the mouse’s
distance from the grid - the further away the mouse is, the shorter
interval.
On each timer timeout, we scroll one line, and update the
selection. Thus, the shorter the interval, the faster we scroll.
The timer is canceled as soon as the mouse enters the grid again, or
the selection is either canceled or finalized.
The timer FD is created and destroyed on-demand.
Most of the logic is now in selection.c. The exception is the
calculation of the timer interval, which depends on the mouse’s
position. Thus, this is done in input.c.
The scroll+selection update logic needs to know a) which direction
we’re scrolling in, and b) which *column* the selection should be
updated with.
If the mouse is outside the grid’s left or right margins, the stored
mouse column will be -1. I.e. we don’t know whether the mouse is on
the left or right side of the grid. This is why the caller, that
starts the timer, must provide this value.
The same applies to top and bottom margins, but since we already have
the scroll *direction*, which row value to use can be derived from this.
If the cursor moves above the grid top, or below the grid bottom,
while selecting text, scroll up/down the scrollback before updating
the selection.
TODO: this only scrolls when the mouse is *moved*. I.e. you can’t move
the cursor outside the grid once and for all, and then let foot
auto-scroll.
Trackpad scroll movements are in pixels. Foot previously “translated”
these directly to line movements (i.e. a one pixel scroll event was
translated into a one line scroll).
Now we use the line height of the terminal and correctly convert
pixels to lines.
This makes the trackpad scroll speed in foot consistent with the
scroll speed in e.g. Alacritty and Kitty.
Allow a mouse binding to match even if its click count is less than
the actual click count.
If there are multiple bindings that match, use the one with the
highest click count (that less than, or equal to the actual click
count).
Closes#146
The keycodes will change if the seat’s keymap changes. Make sure we
only do alternate scrolling if the seat has a keyboard, and use
the *current* layout’s keycodes for arrow up/down (instead of
the *first* layout’s).
This deprecates/renames scrollback-up/down to scrollback-up/down-page.
It also renames scrollback-up/down-half to
scrollback-up/down-half-page, and adds the new bindings
scrollback-up/down-line.
This introduces a new state to a seat's mouse struct, 'consumed'. It
is set on a mouse *press* event that is claimed by a mouse binding.
It is cleared after a mouse *release* event.
While set, *no* mouse motion or button events are sent to the client
application.
Shift is used to enable selection when the client application is
grabbing the mouse.
As such, mouse bindings *never* have Shift as a modifier, but should
still trigger when Shift is being pressed.
