The main culprit was the calloop feature that is used by default
in the underlying SCTK crate.
This commit:
* Routes keyboard processing via the same keyboard mapping code
that we use for X11
* Implements key repeats directly, and with awareness of elapsed
time in case the repeat rate is quicker than the event dispatching
quantum
* Disables the calloop feature of SCTK and let us do our own polling
of the wayland connection.
Critically, key repeat is sticky and unpredictable while calloop is
enabled.
closes: #669
This simplifies it a bit and exposes the config via the config file;
the following options are possible, each one specifies a color
```lua
return {
window_frame = {
inactive_titlebar_bg = "",
active_titlebar_bg = "",
inactive_titlebar_fg = "",
active_titlebar_fg = "",
inactive_titlebar_border_bottom = "",
active_titlebar_border_bottom = "",
button_fg = "",
button_bg = "",
button_hover_fg = "",
button_hover_bg = "",
}
}
```
refs: https://github.com/wez/wezterm/issues/761
This isn't perfect by any means:
* Should allow configuring a sans-serif font
* Emoji need to be scaled
but it allows us to upgrade SCTK without loosing the titlebar
or any control over client side decorations.
You can run `cargo build --release --no-default-features` to build
without wayland support.
This is useful for systems that do not have wayland (eg: the `slint`
distro).
This section of the code wasn't looking up the custom glyphs
and would always use the font. We can make rendering a little
more efficient if we skip the font resolution for this case,
and the code is much simpler if we just use our own box drawing
glyphs, so that's what we're doing here.
refs: #584
This adjusts the cursor position after emitting a sixel.
@dankamongmen: I don't have much of a sixel test suite to speak
of (cat snake.six :-p); I'd appreciate it if you could run
notcurses against this and confirm that it is doing something
sane!
At the very least, we shouldn't be warning about the unhandled
mode any more!
refs: https://github.com/wez/wezterm/issues/863
refs: https://github.com/dankamongmen/notcurses/issues/1743
Rust hasn't stabilized fallible allocation, so when we are presented
with an implausibly large sixel, Rust terminates the program; it's not
even a panick that we could potentially catch -> direct to termination.
This commit introduces an arbitrary constraint so that we can
avoid unconditionally terminating for this bad input case.
Thanks to @klamonte for sharing this test case!
The issue is that the pane was only removed from the tab when explicitly
closed, leaving it to be later detected and flushed.
However, in the meantime, when performing eg: cursor blink maintenance,
if the set of panes in the tab is empty then the window would close.
The resolution is to ask the mux (rather than the tab) to kill the pane,
so that the cascading closure of the tab causes the window's active
tab to reference the correct remaining tab.
refs: #890
