When we receive a keyboard_key or pointer_motion event without first
having received a keyboard_enter or pointer_enter event (that being
the "sway bugs" part), we generally don't know _which_ terminal window
the event was intended for.
However, if we only have *one* window open (always the case for a
regular 'foot' process, or when there's a single footclient connected
to a foot server process), then obviously we can "guess" which window
the event was intended for... so do that.
Now, the only time the event is ignored is when we're a server process
with more than one window open (= more than one footclient connected).
I.e. what we're effectively doing is *not* repeating modifier
keys.
Besides being the "right" thing to do, this also works around another
Sway 1.2 bug, where being in a focused foot window and then switching
to a vt and back would cause us to be stuck in an endless key repeat
loop that would only stop when unfocusing, focusing back and then
unfocusing once again.
Sway 1.2 has been seen sending keyboard_key() events without first
sending a keyboard_enter() event.
This can be triggered by:
1. start a foot terminal
2. unfocus it (move focus to another window)
3. switch to a vt
4. switch back to sway
5. focus the foot terminal
At this point, Sway will *not* send the keyboard_enter() event, but
instead send a keyboard_key() event.
(furthermore, if you now unfocus the window again, sway will send a
keyboard_leave() event, still without having sent a keyboard_enter()
event).
Sway has _also_ been seen crashing in wl_pointer_motion(). Though this
was in a build without proper debug information, everything points to
a similar issue - i.e. sway is sending a motion event without first
having sent an enter event.
Workaround this by detecting this and logging a warning the first time
it happens. The event is then ignored.
This fixes an assertion when holding in ctrl+shift+c (copy to
clipboard); subsequent "presses" would set the clipboard serial to 0,
which we would then assert on in the next iteration when we tried to
cancel the previous copy.
This happens on Sway when exiting a screen locker. Or at least that's
when we see the problem; it's unclear if the event occurs when
starting the screen locker, or when exiting it. Or maybe its both.
Anyway, don't try to unfocus a NULL-terminal.
This reverts commit 739c5cf7f0.
The original commit stated:
Not sure why these were added here; they don't appear to be
needed (we're writing to the client - it's up to the client to echo
stuff, in which case we redraw as usual).
But, client output doesn't cause a scrollback/view reset.
Not sure why these were added here; they don't appear to be
needed (we're writing to the client - it's up to the client to echo
stuff, in which case we redraw as usual).
This ensures we always have a valid (but possibly incorrect) scaling
value. This allows us to simplify code that uses the scale - it
doesn't have to verify the scale if valid.
Furthermore, since render_resize() is the function that actually
updates term->scale, make sure to call it *before* updating the
cursor (otherwise, the cursor will use the old scaling value).
This adds a new state, 'is_searching'. While active, input is
re-directed, and stored in a search buffer. In the future, we'll use
this buffer and search for its content in the scrollback buffer, and
move the view and create a selection on matches.
When rendering in 'is_searching', everything is dimmed. In the future,
we'll render the current search buffer on-top of the dimmed "regular"
terminal output.
When handling keys without a specific map defined (i.e. keys
corresponding roughly to xterm's "otherKeys"), recognize the meta
modifier and report the correct modifier code.
Instead of running a repeater thread that writes the key to repeat
over a pipe, use a simple timer fd.
No more locking or condition signalling. No need to track
start/stop/exist states.
We simply set up the initial timeout value to be the 'delay', and the
interval to be the repeat 'rate'.
The 'attributes' struct is now 8 bytes and naturally packed (used to
be 9 bytes, artificially packed).
'cell' struct is now 12 bytes, naturally packed (used to be 13 bytes,
artificially packed).
Furthermore, the glyph is stored as a wchar instead of a char*. This
makes it easier (faster) to do glyph lookup when rendering.
* Start selection on mouse button down
* Update selection on motion
* Button release cancels selection if there were no motion after start
* Renderer detects cells inside the selection and inverts their colors
