When closing the window via a compositor shortcut, or clicking the CSD
close button, we kill the client application by sending it SIGHUP (and
then SIGTERM followed by SIGKILL, if it refuses to die).
Many shells either don't catch SIGHUP, causing us to exit with a
non-zero value, or they catch it, and then _they_ exit with a non-zero
value, causing _us_ to propagate that to the user.
This patch changes foot's behavior to "ignore" death-by-sighup, and
always exit with value 0.
The log message is changed to debug level, for SIGHUP only; other
death-by-signal is still logged at the warning level.
When trying to match key bindings, we do three types of matching:
* Match the _translated_ symbol (e.g. Control+C)
* Match the _untranslated_ symbol (e.g. Control+Shift+c)
* Match raw keyboard codes
This was done for *each* key binding. This meant we sometimes matched
a keybinding in raw mode, even though there was a
translated/untranslated binding that would match it too. All depending
on the internal order of the key binding list.
This patch changes it, so that we first try all bindings in translated
mode, then all bindings in untranslated mode, and finally all bindings
in raw mode.
Closes#1929
The protocol states:
If the width or height arguments are zero, it means the client
should decide its own window dimension. This may happen when the
compositor needs to configure the state of the surface but doesn't
have any information about any previous or expected dimension.
The wording is a bit ambiguous; does it mean we should set *both*
width and height to values we choose, even if only one dimension is
zero in the configure event? Or does it mean that we should choose the
value for the dimension that is zero in the configure event?
Regardless, it's pretty clear that it does *not* mean we should *only*
choose width and height if *both* dimensions are zero in the configure
event. This is foot's behavior before this patch, meaning if only one
of them is zero, foot assumed the compositor wanted us to set the
width (or height) to zero...
Change this, so that we now choose value for the "missing" dimension,
but do use the compositor provided value for the other dimension.
Closes#1925
Relevant issues:
* https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/155
* https://github.com/YaLTeR/niri/issues/1050
When printing a double-width glyph at the end of the line, it will get
pushed to the next line if there's only one cell left on the current
line.
That last cell on the current line is filled with a SPACER value.
When reflowing the text, the SPACER cell should be "removed", so that
the double-width glyph continues directly after the text on the
previous line.
9567694bab fixed an issue where
reflowing e.g. neofetch output incorrectly removed spaces between the
logo, and the system info. But also introduced a regression where
SPACER values no longer are removed.
This patch tries to fix it, by adding back empty cells, but NOT SPACER
cells.
When alternate key reporting is enabled (i.e. when we're supposed to
report the shifted key along with the unshifted key), we try to figure
out whether the key really is shifted or not (and thus which xkb
keysym to use for the unshifted and shifted keys in the escape).
This was done by getting the layout's *all* modifier combinations that
produce the shifted keysym, and if any of of them contained a modifier
that isn't supported by the kitty protocol, the shifted and unshifted
keys are derived from the same keysym. This is to ensure we handle
things like AltGr-combos correctly.
The issue is, since there may be more than one modifier combination
generating the shifted keysym, we may end up using the wrong keysym
just because _another_ combination set contains modifiers not
supported by the kitty protocol. What we're interrested in is whether
the *pressed* set of modifiers contains such modifiers.
Closes#1918
If the compositor sends a keyboard enter event before our window has
been mapped, foot crashes; the enter event triggers a cursor
refresh (hollow -> non-hollow block cursor), which crashes since we
haven't yet allocated a grid.
Fix by no-op:ing the refresh if the window hasn't been configured yet.
Closes#1910
From the release notes:
system bell - allowing e.g. terminal emulators to hand off system
bell alerts to the compositor for among other things accessibility
purposes
The new protocol is used when the new config option
bell.system=yes (and the compositor implements the protocol,
obviously).
The system bell is rung independent of whether the foot window has
keyboard focus or not (thus relying on compositor configuration to
determine whether anything should be done or not in response to the
bell).
The new option is enabled by default.
If the compositor sends a keyboard enter event before our window has
been mapped, foot crashes; the enter event triggers a cursor
refresh (hollow -> non-hollow block cursor), which crashes since we
haven't yet allocated a grid.
Fix by no-op:ing the refresh if the window hasn't been configured yet.
Closes#1910
A compositor will not send a frame callback for our main window if it
is fully occluded (for example, by a fully opaque overlay...). This
causes the overlay to stuck.
For regular buffers, it _should_ be enough to *not* hint the
compositor it's opaque. But at least some compositor special cases
single-pixel buffers, and actually look at their pixel value.
Thus, we have two options: implement frame callback handling for the
overlay sub-surface, or ensure we don't use a fully opaque
surface. Since no overlays are fully opaque by default, and the flash
surface is the only one that can be configured to be
opaque (colors.flash-alpha), and since adding frame callback handling
adds a lot of boilerplate code... let's go with the simpler solution
of
Unsure if the protocol imposes a limit (haven't found any
documentation), or if the issue is in the libwayland implementation,
or wlroots (triggers in at least sway+river).
The issue is that setting a too long app-id causes the
compositor (river at least) to peg the CPU at 100%, and stop sending
e.g. frame callbacks to foot.
Closes#1897
From the specification:
The Enter, Tab and Backspace keys will not have release events
unless Report all keys as escape codes is also set, so that the
user can still type reset at a shell prompt when a program that
sets this mode ends without resetting it.
Closes#1892
It appears to be slightly more up-to-date with recent Unicode
versions.
In particular, it handles the new "Symbols for Legacy Computing
Supplement" block, introduced in Unicode 16.
Closes#1865
This fixes flickering when foot is forced to double-buffer (e.g when
running under KDE, or smithay based compositors).
Since the damage region isn't updated, the sixel images aren't
included in the memcpy that is done to transfer the last frame's
updated regions to the next frame.
As a result, every other frame will have the sixels, while the others
don't.
Closes#1851
When trying to set a custom cursor shape, we first validate it. This
is done by checking against known server-side names, and then trying
to load the cursor from the client side cursor theme.
But, if we're using server side names, there is no theme loaded, and
foot crashed.
Fix by checking if we have a theme loaded, and if not, fail the cursor
shape name validation.
