This commit ties our invalidation requests together with the surface
frame callback request so that we can throttle our frame rate if
we're busy, but still remain largely idle if we're not changing
any content.
refs: https://github.com/wez/wezterm/issues/884
https://emersion.fr/blog/2018/wayland-rendering-loop/ suggests that
it is best practice to do this so that the compositor doesn't
cause an application to block forever if the window is moved to
an off-screen state.
That article also suggests using the frame callback to schedule
paints; this commit has that code included, but I've left it
disabled because it causes us to repaint at the monitor refresh
rate which is often more frequently than we would anyway;
in our problem scenario we're painting once per second and we
just want to make sure that that doesn't block.
So hopefully this makes the sway/scratchpad experience better!
refs: https://github.com/wez/wezterm/issues/884
WindowState is a bitfield that can represent maximized, full screen
and hidden window states.
WindowState is passed along with resize events, improving on the
prior basic is_full_screen boolean by representing the other states.
Notably, WindowState::MAXIMIZED is used to represent a state where
the window's size is constrained by some window environment function;
it could be due to the window being maximized in either or both the
vertical or horizontal directions, or by the window being in a tiled
state on any edge.
When the window is MAXIMIZED, wezterm will behave as though
`adjust_window_size_when_changing_font_size = false` because it knows
that it cannot adjust the window size in that state.
This potentially helps with #695, depending on whether the window
manager propagates this state information to wezterm. Gnome/mutter
does a good job at this with both X11 and Wayland, but I couldn't get
sway to report these states and I don't know of any other tiling wm
that I can easily install and use on fedora, so there's a question
mark around that.
Switch to using `xterm` rather than `text` for the name of the
xterm style I-beam mouse cursor, as that appears to be more
compatible across themes; the gnome theme aliases text -> xterm
via a symlink.
Improve error diagnostics in the case that no cursor is found.
refs: https://github.com/wez/wezterm/issues/532
Avoid setting the title again if it matches the last thing we set;
this in turn avoids receiving a property update from the window
manager to tell us that we set the title.
refs: #964 (but isn't the root cause)
This commit causes a window-config-reloaded event to trigger
when the appearance (dark/light mode) is changed on macos.
It also arranges to propagate the window level config to newly
spawned panes and tabs, created both via the gui and via the
CLI/mux interface.
refs: https://github.com/wez/wezterm/issues/894
refs: https://github.com/wez/wezterm/issues/806
I added this originally thinking that it would make it easier to resolve
https://github.com/wez/wezterm/issues/695 and to integrate wgpu support,
but it's the cause of https://github.com/wez/wezterm/issues/922 so let's
take it out and more directly connect the window events to those in the
terminal.
This commit likely breaks mac and windows; pushing it so that I can
check it out and verify on those systems.
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).
in https://github.com/wez/wezterm/issues/767 CTRL-Tab was getting
incorrectly normalized to CTRL-i; that normalization is valid (Tab is
actually equivalent to CTRL-i as far as unix terminals are concerned)
but unwanted at this layer.
I suspect that this change will come back to haunt me in the future,
as keyboard input is a bit of a zoo.
At the bottom of https://github.com/wez/wezterm/issues/815 is some
discussion about an apparent hang.
Let's make the self pipe writing a bit more robust and log to see
if that might be related.