Since fonts are cached, this adds no additional memory. However, it
makes the first terminal window in --server mode start much faster,
since the (primary) fonts have already been loaded.
Fallback fonts are still loaded on-demand.
In this mode, foot listens on a UNIX socket and creates terminal
windows when clients connect.
A connecting client sends argc/argv to the server, and the server
instantiates a new terminal window.
When the terminal window is closed, the exit code is sent back to the
client.
We do however need access to it, so provide a pointer. The difference
is that now we can have a *single* wayland instance, but multiple
terminal instances.
Short term, we want to break out the wayland backend from the terminal
struct. Long term, we might want to support multiple windows.
One step towards both the above is separating global wayland objects
from per-window objects.
run_command() was only run at configure time, meaning the generated
version (that was passed on to the sources via -DFUZZEL_VERSION)
became stale.
Fix by implementing a shell script that generates a header file, and
wrap this in a custom target that is run every time (but the generated
file is only updated when the version changes)
This is used in the desktop startup notification protocol. We don't
support it (is it even used on Wayland?), but need to ensure programs
launced from within foot doesn't inherit it.
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 makes -f,--font behave just like the configuration file option
'font'; the first font in the list is the primary font, and the
remaining fonts are fallback fonts used when a glyph cannot be found
in the primary font.
This fixes an issue where sometimes the strikeout thickness where
truncated to 0 (e.g. Cascadia Code).
Note that we already do this for the underline calculations.
We now use two timers for delayed rendering; one _lower_ limit timeout
that is reset each time we receive input from the slave. We never
render *before* this timeout. Since it's reset, this means rendering
may be pushed further into the future.
To prevent this from happening indefinitely, the second timer defines
the _upper_ limit. This timer is only reset after rendering.
Thus, slave input may now increase the rendering delay, but only up to
a certain limit.
The lower limit is as before, 1ms. The upper limit is set to 16ms (the
time between frame updates on a 60HZ output).
This ensures we never wait *longer* than 1ms (previously, we could end
up doing multiple polls, each with a timeout value of 1ms - thereby
potentially delaying the refresh indefinitely).
