This extends the new ‘dpi-aware’ option with a new default value,
‘auto’.
When set to ‘auto’, fonts are sized using monitors’ DPI when output
scaling is disabled. When output scaling is enabled, fonts are instead
sized using the scaling factor.
The reasoning here is that a user that has enabled output scaling is
obviously *not* relying on DPI scaling.
Output scaling can also be a way to compensate for different viewing
distances, in which case we do *not* want to break that by using DPI
scaling.
Users can still force DPI-only font sizing by setting ‘dpi-aware=yes’,
or disable it completely by setting ‘dpi-aware=no’.
Take ‘\E(#0’ for example - this is *not* the same as ‘\E(0’.
Up until now, foot has however treated them as the same escape,
because the handler for ‘\E(0’ didn’t verify there weren’t any _other_
private characters present.
Fix this by turning the ‘private’ array into a single 4-byte
integer. This allows us to match *all* privates with a single
comparison.
Private characters are added to the LSB first, and MSB last. This
means we can check for single privates in pretty much the same way as
before:
switch (term->vt.private) {
case ‘?’:
...
break;
}
Checking for two (or more) is much uglier, but foot only supports
a *single* escape with two privates, and no escapes with three or
more:
switch (term->vt.private) {
case 0x243f: /* ‘?$’ */
...
break;
}
The ‘clear’ action remains simple (and fast), with a single write
operation.
Collecting privates is potentially _slightly_ more complex than
before; we now need mask and compare, instead of simply comparing,
when checking how many privates we already have.
We _could_ add a counter, which would make collecting privates easier,
but this would add an additional write to the ‘clean’ action which is
really bad since it’s in the hot path.
This fixes issues with de-synchronized frames being rendered; we may
have scheduled a redraw earlier, that hasn’t yet triggered (probably
because we’re waiting for a frame callback), when we enable
application synchronized updates.
This means we risk rendering a partially updated state when the frame
callback finally arrives, if the application hasn’t yet ended its
synchronized update.
Well this is embarrassing; the sub-parameter versions of the 38/48 SGR
escapes all required an extra ‘:2’ that wasn’t supposed to be there,
causing all the other sub-parameters to be shifted one step to the
right.
That is, foot expected e.g. 38:2:2:r:g:b, or 38:2:5:idx when the
correct sequences are 38:2:cs:r:g:b and 38:5:idx.
I.e. I mixed up the color-space ID (cs) of 38:2 with *type* of color:
RGB or indexed.
In addition to fixing this, this patch also adds support for a
“bastard” version of the sub-parameter based RGB escapes, where the
color-space identifier has been left out: e.g. 38:2:r:g:b. This
sequence is invalid, but applications tend to “forget” the color-space
ID...
As long as the mouse button was *pressed* while the pointer was inside
the grid, we want to keep reporting motion events until the button is
released.
Even when the pointer moves outside the grid (but in this case, the
reported coordinates are bounded by the grid size).
This patch also tries to improve multi-button handling (i.e. multiple
buttons pressed at the same time), and the events we report to the
client for these, in the following ways:
* Motion events now report the *initial* button. That is, if you start
a drag operation with the LEFT button, then press RIGHT (before
releasing LEFT), keep reporting LEFT in the motion events.
* Mouse release events are reported for *any* button, as long as the
pointer is *inside* the grid, *or*, the button released was the
button used to start a drag operation.
The last point is important; if we have reported a button press
followed by motion events (i.e. a drag operation), we need to report
the button release, *even* if the pointer is outside the grid.
Note that the client may receive unbalanced button press/release
events in the following ways if the user pressed one, and then a
second button *inside* the grid, then releases the *first*
button (possibly outside the grid), and finally releases the *second*
button *outside* the grid.
In this case, both buttons will report press events. The first button
will report a release event since it is the initial button in the drag
operation.
However, we don’t track the fact that the second button is being
pressed, and thus if it is released outside the grid, it wont generate
a release event.
OSC 777 is URxvt’s generic escape to send commands to its perl
extensions. The first parameter is the name of the extension, followed
by its arguments.
OSC 777;notify is a, if not well established, at least a fairly well
known escape sequence to request a (desktop) notification. The syntax
is:
\e]777;notify;<title>;<body>\e\\
Neither title nor body is escaped in any way, meaning they should not
contain a ‘;’.
Foot will split title from body at the *first* ‘;’. Any remaining ‘;’
characters are treated as part of ‘body’.
Instead of adding built-in support for the freedesktop notification
specification (which would require us to link against at least dbus),
add a new config option to foot.ini: ‘notify’.
This option specifies the command to execute when a notification is
received. ‘${title}’ and ‘${body}’ can be used anywhere, in any
combination, and as many times as you want, in any of the command
arguments.
The default value is ‘notify-send -a foot -i foot ${title} ${body}’
Previously, foot would not accept the following:
[key-bindings]
minimize=Escape
minimize=Escape
Now it does. I.e. key combos in the action being updated are ignored
when detecting collisions.
The example above is contrived; a real world example could be to
remove certain combos from an action with multiple combos; perhaps to
free up a combo for another action. Example:
[search-bindings]
cancel=Escape
This would previously cause an error since `cancel=Control+g Escape`
by default.
Closes#233
All alt+return combos mapped to the same escape sequence as alt+return
itself.
With this patch, alt+<mod(s)>+return map to a standard ‘CSI 27;x;13~’
sequence.
With XKB, Shift+Tab maps to XKB_KEY_ISO_Left_Tab, not
XKB_Key_Tab. Previously, we had two different lookup tables for the
two.
The tab table was correctly populated, while the ISO-left tab
wasn’t. As a result, all Shift+Tab combos (except Shift+Tab itself)
was wrong, and resulted in the same escape sequence as Shift+Tab.
Fix by using the same table for both tab and ISO-left tab.
Closes#210
A configure event must be “committed”. In case of resizing, that means
rendering a new frame and committing that surface.
render_resize() will resize the grid and *schedule* a render
refresh. However, if one is already pending, the refresh will take a
very (relatively) long time - until the next frame callback is
received.
This poses a problem when the window is hidden, since in this case,
the frame callback *never* comes. This in turn means we fail to commit
a new surface in response to the ‘configure’ event. And that means the
compositor needs to wait for a transaction timeout before continuing.
The end effect is very slow and jerky window resizing when a hidden
foot window is being resized.
This can happen in tiled compositors, like Sway, where a window can be
tabbed (and thus invisible), but still resized when its container is
resized.
Closes#190
There are two different escape sequences that can be used to set the
cursor blink state: ‘CSI ? 12 h/l’ and ‘CSI Ps SP q’.
Up until now, they both modified the same internal state in foot. This
meant you could enable a blinking cursor with e.g. ‘CSI ? 12 h’ and
then disable it with ‘CSI 2 SP q’.
Since the ‘CSI ? 12’ escapes are used in the civis/cnorm/cvvis
terminfo entries, applications often ended up disabling the blink
state on exit (typically be emitting ‘cnorm’), requiring users to
manually re-enable blinking.
By splitting the internal state into two separate states, we can
improve the situation.
The cursor will blink if at least one of the two have been enabled.
The setting in foot.ini sets the default state of the ‘CSI Ps SP q’
escape.
This means if the user has enabled blinking in the configuration, the
cursor will blink regardless of civis/cnorm/cvvis. Which probably is
what the user wants.
If the user has NOT enabled blinking, civis/cnorm/cvvis act as
intended: cvvis blink, civis and cnorm do not.
If an application overrides the cursor blink/style with ‘CSI Ps SP q’,
that will override the user’s setting in foot.ini. But most likely
that too is intended (for example, the user may have configured the
application to use a different cursor style). And, a well written
application will emit the ‘Se’ terminfo sequence on exit, which in
foot is defined to ‘CSI SP q’, which will reset both the style and
blink state to the user configured style/state.
Closes#218
