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.
Summary of changes:
* Make xvsnprintf() static
* restrict-qualify pointer arguments (as done by the libc equivalents)
* Make comments and spec references more thorough
* Remove pointless `n <= INT_MAX` assertion (see comment)
* Use FATAL_ERROR() instead of xassert() (since the assertion is inside
a shared util function but the caller is responsible for ensuring the
condition holds true)
* Change some callers to use size_t instead of int for the return value
(negative returns are impossible and all subsequent uses are size_t)
The updated comments and code were taken (and adapted) from:
49260bb154/src/util/xsnprintf.c (L6-50)
This work was entirely authored by me and I hereby license this
contribution under the MIT license (stated explicitly, so that
there's no ambiguity w.r.t. the original license).
The config system allows setting the scrollback lines to
2**32-1.
However, the total number of grid lines is the scrollback lines plus
the window size, and then rounded *up* to the nearest power of two.
Furthermore, the number of rows is represented with a plain 'int'
throughout the code base.
The largest positive integer that fits in an int is 2**31-1. That
however, is not a power of two.
The largest positive integer, that also is a power of two, that fits
in an int is 2**30, or 1073741824.
Ideally, we'd just cast the line count to a 64-bit integer, and call
__builtin_clzl{,l}() on it, and then take the smallest value of that,
or 2**30. But, for some reason, __builtin_clzl(), and
__builtin_clzll() appears to ignore bits above 32, despite they being
typed to long and long long. Bug?
Instead, ensure we never call __builtin_clz() on anything larger than
2**30.
Closes#1828
That is, skip the reverse DNS naming scheme suggested by the .desktop
specification, and directly match our app-ids ("foot", and
"footclient").
This simplifies .desktop -> window instance mapping, allowing DEs to
match the filenames directly, without having to look at the
StartupWMClass key in the .desktop files.
These are the original names of the .desktop files. There were
renamed (to use the reverse DNS syntax) to please the flathub people,
who *required* this scheme to accept the foot package.
But, since:
* We don't package foot ourselves
* We don't go out of our way to support non-distro packaging schemes
* Flathub still hasn't merged the foot PR (it's now 2 years old)
* There are no know issues in any known DE that prevents a non-reverse
DNS .desktop filename from working
* There are plenty of other applications that doesn't use reverse DNS
names (a very clear majority, in my case)
Let's just revert back to the simpler naming scheme.
Closes#1607
The wording in the original VT340 documentation is vague:
Pixel positions specified as 0 are set to the current background
color.
What does that mean? We _thought_ it meant the current ANSI background
color, as set with e.g. CSI 4x m.
It's still all a bit vague, but seeing that we have separate palettes
for text and graphic (should we?), it doesn't make sense to use the
ANSI background color as the default sixel background color.
So, use entry 0 from the sixel palette instead.
Or put more propertly; if the notification daemon, and the
notification helper used by foot has been configured
properly (i.e. they both support XDG activation tokens), notifications
generated by BEL and OSC-777 will now raise/focus the window when the
default action of the notification is activated - typically by
clicking the notification.
Closes#1822
When the background alpha changes from fully opaque, to transparent,
or vice versa, we need to do more than just repaint the affected
cells.
For example, we need to create new surfaces with the correct pixel
format.
OSC-11 (set background color) already does this, but the same alpha
checking logic was missing in OSC-111 (reset background color).
Fixes#1801
When doing locale fallback, and printing user notifications and log
warnings, better separate the case "locale is invalid" from "locale is
valid but not UTF-8".
Closes#1798
* The spec now defines a couple of "standard" names. Translate these
to the freedesktop compliant names.
* The query response no longer contains 'xdg-names', but instead list
the supported standard names.
* Render button as highlighted only when pointer is above them
* Releasing the mouse button while *not* on the button does *not*
activate the button
When pressing, and holding, a mouse button, the compositor keeps
sending motion events for the surface where the button was pressed,
even if the mouse has moved outside it.
We also don't get any surface leave/enter events.
This meant that the button was rendered as highlighted, and a click
registered, if the user pressed the mouse button while on the button,
and then moved the cursor away from the button before releasing the
button.
This patch fixes it, by checking if the current cursor coordinates
fall within the button surface.
This is how most UIs work.
Note that we (at least on River) don't get any surface enter/leave
events while a button is held. This means we can't detect if the user
pressed the mouse button while on a CSD button, but then moves the
mouse outside. Releasing the mouse button will still activate the CSD
button.
Closes#1787
