Before this patch, we asserted both the cursor foreground, and
background colors had been set. This is true in most cases; the config
system enforces it.
It is however possible to set only the cursor background color, while
leaving the foreground (text) color unset:
* Use a foot config that does *not* configure the cursor colors. This
means foot will invert the default fg/bg colors when rendering the
cursor.
* Override the cursor color using an OSC-12 sequence. OSC-12 only sets
the background color of the cursor, and there is no other OSC sequence
to set the cursor's text color.
To handle this, remove the assertion, and simply split the logic for
the cursor backgound and foreground colors:
* Use the configured background color if set (either through config or
OSC-12), otherwise use the default foreground color.
* Use the configured foreground color if set (through config),
otherwise use the default background color.
Try to make the 'dotted' style appear more even, and less like each
cell is rendered separately (even though they are).
Algorithm:
Each dot is a square; it's sides are that of the font's line
thickness.
The spacing (gaps) between the dots is initially the same width as the
dots themselves.
This means the number of dots per cell is the cell width divided by
the dots' length/width, divided by two.
At this point, there may be "left-over" pixels.I.e. the widths of the
dots and the gaps between them may not add up to the width of the
cell.
These pixels are evenly (as possible) across the gaps.
There are still visual inaccuracies at small font sizes. This is
impossible to fix without changing the way underlines are rendered, to
render an entire line in one go. This is not something we want to do,
since it'll make styled underlines, for a specific cell/character,
look differently, depending on the surrounding context.
When doing an interactive resize, we create a small grid copy of the
current viewport, and then do a non-reflow resize.
When the interactive resize is done, we do a proper reflow. This is
for performance reasons.
When creating the viewport copy, we also need to copy the styled
underlines. Otherwise, styled underlines will be rendered as plain
underlines *while resizing*.
This was originally contributed by @kraftwerk28 in
https://codeberg.org/dnkl/foot/pulls/1099
Here, we re-use the rendering logic only, as attribute tracking has
been completely rewritten.
This is work in progress, and fairly untested.
This adds initial tracking of styled underlines. Setting attributes
seems to work (both color and underline style). Grid reflow has *not*
been tested.
When rendering, style is currently ignored (all styles are rendered as
a plain, legacy underline).
Color however, *is* applied.
Don't re-create the single-pixel buffer, unless necessary.
The buffer itself doesn't have a size. That means we can re-use the
buffer if the last frame's overlay style matches the current frame's
style.
What we *do not* know is whether the current frame's size is the same
as the last frame's.
This means we still have to set the viewport destination, and commit
the surface.
The unicode-mode, and flash overlays are single color buffers. This
means we can use the single-pixel buffer protocol.
It's undefined whether the compositor will release the buffer or not;
to make things easier, simply destroy the buffer as soon as we've
committed it.
Note that since compositors don't necessarily release single-pixel
buffers, we can't plug them into our own buffer interface. This means
we can't use buffer pointers to check if we can re-use the previous
buffer (i.e. we can skip comitting a new buffer), or if we have to
create a new one.
It's _almost_ enough to just check if the last overlay style is the
same as the current one. Except that that doesn't take window resizes
into account...
This fixes an issue where entering unicode-mode in one foot client,
also enabled unicode-mode on other foot clients. Both
visually (although glitchy), and in effect.
The reason the state was originally in the seat objects, was to fully
support multi-seat. That is, one seat/keyboard entering unicode-mode
should not affect other seats/keyboards.
The issue with this is that seat objects are Wayland global. Thus, in
server mode, all seat objects are shared between the foot clients.
There is a similarity with IME, which also keeps state in the
seat. There's one big difference, however, and that is IME has Wayland
native enter/leave events, that the compositor emits when windows are
focused/unfocused. These events allow us to reset IME state. For our
own Unicode mode, there is nothing similar.
This patch moves the Unicode state from seats, to the terminal
struct. This does mean that if one seat/keyboard enters Unicode mode,
then *all* seats/keyboards will affect the unicode state. This
potential downside is outweighed by the fact that different foot
clients no longer affect each other.
Closes#1717
This option controls how we render the cursor when the terminal window
is unfocused.
Possible values are:
* hollow: the default, and how we rendered the cursor before this
patch.
* unchanged: render the cursor exactly the same way as when the window
is focused.
* none: do not render any cursor at all
Closes#1582
Before this patch, we used legacy X11 xcursor names, and didn't really
have any fallback handling in place (we only tried to fallback to
"xterm", regardless of which cursor shape we were trying to load).
This patch changes two things:
1. Improved fallback support. cursor_shape_to_string() now returns a
list of strings. This allows us to have per-shape fallbacks, and any
number of fallbacks.
2. We prefer CSS xcursor names over legacy X11 names.
render_xcursor_update() is called when we've loaded a new xcursor
image, and needs to display it. The reason it's not pushed to the
compositor immediately is to ensure we don't flood the Wayland socket
with xcursor updates.
Normally, it's only called when we *succeed* to load a new xcursor
image. I.e. if we try to load a non-existing xcursor image, we never
schedule an update.
However, we _can_ still end up in render_xcursor_update() without a
valid xcursor image. For example, we have loaded a valid xcursor
image, and scheduled an update. But before the update runs, the user
moves the cursor, and we try to load a new xcursor image. If it fails,
we crash when the previously scheduled update finally runs.
Closes#1624
This adds support for a new OSC escape sequence: OSC 176, that lets
terminal programs tell the terminal the name of the app that is
running. foot then sets the app ID of the toplevel to that ID,
which lets the compositor know which app is running, and typically
sets the appropriate icon, window grouping, ...
See: https://gist.github.com/delthas/d451e2cc1573bb2364839849c7117239
This boolean isn't needed. The idea was probably to not re-program the
timer unnecessarily, or even to prevent it from being moved forward in
time indefinitely.
However, the logic has (probably) gone through some changes, that now
makes it irrelevant.
The timer isn't moved forward indefinitely; it is always set to 8ms
from the last title update. The closer we get to that point in time,
the smaller the timeout we set.
Now, is_armed _did_ prevent the timer from being re-programmed. But
that tiny performance tweak isn't really necessary, as the title
should, in normal cases, not be set that often anyway.
An opaque sixel that isn't a multiple of the cell size will have some
cells partially visible (either the entire last row, the entire last
column, or both).
These must be rendered before blitting the sixel.
f5f2f5a954 introduced a regression,
where all such cells were rendered as if the cursor was there, giving
them the wrong appearance.
Closes#1520
Pass a damage region to render_row()/render_cell() when rendering
partially visible cells underneath a sixel.
This ensures the affected regions are later reported as 'damaged' to
the Wayland compositor.
Closes#1515
Before this patch. Wayland surface damage tracking was done on a
per-row basis. That is, even if just one cell was updated, the entire
row was "damaged".
Now, damage is per cell. This hopefully results in lower latencies in
many use cases, and especially on high DPI monitors.
Rewrite render_osd(), and instead of passing in an y-offset, let
render_osd() itself center the text inside the OSD buffer.
This is done using the same baseline calculation term_font_baseline()
does, except we use the buffer height instead of the line height.
Note that most OSDs are sized based on the line height...
Closes#1430
Before this patch, we didn’t ensure width and height were valid for
the current scaling factor, when fractional scaling _is_
available. That is, we didn’t ensure the width/height values
multiplied back to their original values after dividing with the
scaling factor.
Closes#1446
* Ensure buffer sizes are valid. That is, ensure that
size / scale * scale == size.
* Do size calculation of the window geometry in the same way we
calculate the CSD offsets.
And calculation of compounded offsets/widths/heights, to compensate
for compositor rounding when positioning and scaling/sizing
subsurfaces.
Closes#1441
By how much to increase the luminance when brightening bold
fonts. This was previously hard-coded to a factor of 1.3, which is now
the default value of the new config option.
Closes#1434
render_osd() shouldn't use term_font_baseline().
This is because term_font_baseline() uses the line height to determine
the position, while render_osd() renders to surfaces that aren't sized
like the grid.
This fixes a regression, where the CSD title were sometimes rendered
too high up, and sometimes too low.
* In all calls to wl_subsurface_set_position()
* (wp_viewport_set_destination() already does this)
* Whenever we use the scale to calculate margins (search box,
scrollback indicator etc)
* Since the scaling factor is stored as a float (and not a double),
use roundf() instead of round()
The wayland protocol recommends (or mandates?) that compositors render
a black background behind fullscreened transparent windows. I.e. you
never see what’s _actually_ behind the window.
So, if you have a white, but semi-transparent background in foot,
it’ll be rendered in a shade of gray.
Given this, it’s better to simply disable transparency while we’re
fullscreened. That way, we at least get the "correct" background
color.
Closes#1416
Break out the logic that updates the terminal’s scaling factor value,
from render_resize(), to a new function, term_update_scale(). This
allows us to update the scaling factor without a full grid resize.
We also change how we pick the scaling factor (when fractional scaling
is not in use). Before, we’d use the highest scaling factor from all
monitors we were mapped on. Now, we use the scaling factor from the
monitor we were *last* mapped on.
Then, add a boolean parameter to term_set_fonts(), and when
false, *don’t* call render_resize_force().
Also change term_font_dpi_changed() to only return true if the font
was changed in any way.
Finally, rewrite update_term_for_output_change() to:
* Call term_update_scale() before doing anything else
* Call render_resize{,_force} *last*, and *only* if either the scale
or the fonts were updated.
This fixes several things:
* A bug where we failed to update the fonts when fractional scaling
was in use, and we guessed the initial scale/DPI wrong. The bug
happened because updated the internal "preferred" scale value, and a
later call to render_resize() updated the terminal’s scale value,
but since that code path didn’t call term_font_dpi_changed() (and it
shouldn’t), the fonts weren’t resized properly.
* It ensures we only resize the grid *once* when the scaling factor,
or DPI is changed. Before this, we’d resize it twice. And this
happened when e.g. dragging the window between monitors.
When the user has configured custom cursor colors (cursor.color is set
in foot.ini), don’t invert those colors when the cell is either
selected, or has the ‘reverse’ attribute set.
This aligns foot’s behavior with Alacritty, Kitty and Wezterm. Contour
also behaves similarly, except mouse selections override the cursor
colors (turning the cursor invisible).
Closes#1347
Using a lookup table, try to map the user-provided xcursor string to a
cursor-shape-v1 known shape.
If we succeed, set the user’s custom cursor using server side
cursors (i.e. using cursor-shape-v1).
If not, fallback to trying to load the image ourselves (using
wl_cursor_theme_get_cursor()), and set it using the legacy
wl_pointer_set_cursor().
