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).
Thus, when we call render_resize() with *old* with/height values, we
must scale them back to their original values.
This fixes an issue where, for example, moving a window between
outputs with different scales caused the window to keep growing.
Create the sub-surface once, at startup. Then, instead of destroying
it when committing/cancelling a search, unmap it (by attaching a NULL
buffer to it).
That is, remove the 'regular' and 'bright' color arrays. This is
possible since the 256-color array is defined such that the first 16
colors map to the regular and bright colors.
Our surface may be on multiple outputs at the same time. In this case,
we use the largest scale factor, and let the compositor down scale on
the "other" output(s).
And handle read() returning EAGAIN.
This fixes an issue with the keyboard repeat timer, which sometimes
would return EAGAIN.
Most likely because POLLIN was set on it, but then before we get to
handle it, the timer was canceled (by a key up event).
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'.
Fonts are now loaded with FT_LOAD_COLOR and we recognize and support
the FT_PIXEL_MODE_BGRA pixel mode.
This is mapped to a CAIRO_FORMAT_ARGB32 surface, that is blitted
as-is (instead of used as a mask like we do for gray and mono glyphs).
Furthermore, since many emojis are double-width, we add initial
support for double-width glyphs.
These are assumed to always be utf8. When PRINT:ing an utf8 character,
we check its width, and add empty "spacer" cells after the cell with
the multi-column glyph.
When rendering, we render the columns in each row backwards. This
ensures the spacer cells get cleared *before* we render the glyph (so
that we don't end up erasing part of the glyph).
Finally, emoji fonts are usually bitmap fonts with *large*
glyphs. These aren't automatically scaled down. I.e. even if we
request a glyph of 13 pixels, we might end up getting a 100px glyph.
To handle this, fontconfig must be configured to scale bitmap
fonts. When it is, we can look at the 'scalable' and 'pixelsizefixup'
properties, and use these to scale the rendered glyph.
