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
When building foot with pgo under gentoo's portage, LLVM tried to
generate profile data files directly under system root, triggering
sandbox violation and causing build to fail. Setting this envvar fixes
the issue by explicitly specifying profiling data location.
Reference: https://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation
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 scanning the grid for all-dirty rows (that we can remove from the
damage region we're about to memcpy from the old frame), check the
row->dirty bit, and skip scanning the cells of that row altogether.
We're only looking for rows where all cells are dirty - those rows can
be removed from the region we copy from the old frame, since the
entire row will be re-rendered anyway.
If a row is clean, it *must* be copied from the old frame.
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.
In fact, there appears there *is* no escape sequence to set the icon.
Keep most of the logic in place, but in practice, we'll always set the
icon to the app-id. That is, at startup, we set it to the configured
app-id (either from config, or the command line).
OSC-176, which sets the app-id, also updates the icon (to the app-id).
* The toplevel icon is now set to the app-id, unless "overridden" by
OSC-1 or OSC-0.
* Implemented OSC-1
* OSC-0 extended to also set the icon
* Implemented CSI 20 t - report window icon
* Implemented CSI 21 t - report window title
* Implemented CSI 22 ; 1 t - push window icon
* Implemented CS 23 ; 1 t - pop window icon
* Extended CSI 22/23 ; 0 t to also push/pop the icon
* Verify app-id set by OSC-176 is valid UTF-8
* Verify icon set by OSC-0/1 is valid UTF-8
If the xdg-toplevel-icon-v1 protocol is available, and we have the
corresponding manager global, set the toplevel icon to "foot".
Note: we do *not* provide any pixel data. This is by design; we want
to keep things simple.
To be able to provide pixel data, we would have to either:
* embed the raw pixel data in the foot binary
* link against either libpng or/and e.g. nanosvg, locate, at run-time,
the paths to our own icons, and load them at run-time.
* link against either libpng or/and e.g. nanosvg, and, at run-time, do
a full icon lookup. This would also require us to add a config option
for which icon theme to use.
Of the two, I would prefer the first option. But, let's skip this
completely for now.
By providing the icon as a name, the compositor will have to lookup
the icon itself. Compositors supporting icons is likely to already
support this.
So what do we gain by implementing this protocol? Compositors no
longer has to parse .desktop files and map our app-id to find the icon
to use.
There's one question remaining. With this patch, the icon name is
hardcoded to "foot", just like our .desktop files. But, perhaps we
should use the app-id instead? And if so, should we also change the
icon when the app-id changes?
My gut feeling is, yes, we should use the app-id instead, and yes, we
should update the icon when the app-id is changed at run-time.
