Before this patch, wl_cursor_theme_get_cursor() was called in the FDM
hook, just before we’re about to update the mouse cursor “for real”.
This relies on seat->pointer.xcursor still being valid. This is true
as long as we’re only using our compiled-in static xcursor names, but
not otherwise.
Now, we call wl_cursor_theme_get_cursor() in render_xcursor_set(). At
this point, we *know* seat->pointer.xcursor is valid.
There is a slight chance of added overhead here, if the client
application is switching mouse grabbing on/off rapidly. Before, the
calls to wl_cursor_theme_get_cursor() would automatically be
throttled.
However, the main point of delaying the actual pointer update to the FDM
hook is to throttle the *Wayland* calls. And this is still happening:
wl_cursor_theme_get_cursor() is client-side only.
We calculated the ‘start’ row by adding the number of screen rows to
the current grid offset. This works in most cases. But not when the
offset is close to the wrap-around.
This triggered a crash when we tried to access a row number larger
than the number of available grid rows.
Fix by bounding the start row to the number of grid rows.
This unearthed a second bug, where trying to extract the scrollback
resulted in nothing getting copied.
The extraction logic did:
for (r = start; r != (end + 1); r++)
....
This works, as long as end isn’t start-1. When we try to extract the
entire scrollback, it _is_ start-1.
Fix by rewriting the loop logic to check for r==end *after* copying
the row contents, but *before* incrementing r.
Closes#926
When iterating the characters in a selection, we want to go from the
“start” to the “end”, where start is the upper left-most character,
and “end” is the lower right-most character.
There are two things to consider:
* The ‘start’ coordinate may actually sort after the ‘end’
coordinate (user selected from bottom of the window and upward)
* The scrollback wraparound.
What we do is calculate both the star and end coordinates’
scrollback-start relative row numbers. That is, the number of rows
from the beginning of the scrollback. So if the very first
row (i.e. the oldest) in the scrollback is selected, that has the
scrollback-start relative number “0”.
Then we loop from whichever (start or end coordinate) is highest up in
the scrollback, to the “other” coordinate.
This fixes a crash caused by the selection’s pivot point not being
translated during reflow.
While we could simply reflow the pivot point as well, testing shows
irregular behavior with ongoing selections across window resizes, with
different compositors behaving differently.
For now, we simply finalize the selection, instead of trying to handle
ongoing selections.
Closes#922
Fcft no longer uses wchar_t, but plain uint32_t to represent
codepoints.
Since we do a fair amount of string operations in foot, it still makes
sense to use something that actually _is_ a string (or character),
rather than an array of uint32_t.
For this reason, we switch out all wchar_t usage in foot to
char32_t. We also verify, at compile-time, that char32_t used
UTF-32 (which is what fcft expects).
Unfortunately, there are no string functions for char32_t. To avoid
having to re-implement all wcs*() functions, we add a small wrapper
layer of c32*() functions.
These wrapper functions take char32_t arguments, but then simply call
the corresponding wcs*() function.
For this to work, wcs*() must _also_ be UTF-32 compatible. We can
check for the presence of the __STDC_ISO_10646__ macro. If set,
wchar_t is at least 4 bytes and its internal representation is UTF-32.
FreeBSD does *not* define this macro, because its internal wchar_t
representation depends on the current locale. It _does_ use UTF-32
_if_ the current locale is UTF-8.
Since foot enforces UTF-8, we simply need to check if __FreeBSD__ is
defined.
Other fcft API changes:
* fcft_glyph_rasterize() -> fcft_codepoint_rasterize()
* font.space_advance has been removed
* ‘tags’ have been removed from fcft_grapheme_rasterize()
* ‘fcft_log_init()’ removed
* ‘fcft_init()’ and ‘fcft_fini()’ must be explicitly called
This ensures processes spawned by us (e.g. the shell, new terminal
instances etc) don’t inherit a flawed signal mask, or having signals
unknowingly ignored.
Closes#854
In Sway-1.5, sway waits for configure ACKs from hidden windows when
views are being resized. I.e. if you have e.g. a stacked view, with
one or more windows currently not visible, and you resize the stack,
then sway will emit configure events to all windows, and then wait for
ACKs before rendering the resized view.
The problem with this is that sway also does **not** call frame
callbacks on hidden windows. So if we have rendered one frame, and
thus registered a frame callback, we’ll never render any more frames
until the window becomes visible again. Ergo, if you resize the view
interactively, only the first resize actually happens. After that, all
hidden views are “stuck”, causing ACK timeouts.
We worked around this in foot by preempting the frame
callback. I.e. destroying it, and rendering the frame anyway.
This has fixed in sway-1.6, and thus we can remove the workaround.
