The thesis is that some WM's might send a whole bunch of events
that cause us to over draw/over resize.
I'm not convinced that this is a righteous change, but it can't
hurt to try.
refs: #1051
Some users mentioned that there's a lag after selecting text
on X11. Tracing through, I saw that the we invalidate the window
quite a lot when dragging the selection, and the buffer swap could
delay for several ms each time while waiting for the vsync.
Rather than blocking the GUI thread and making it bog down, this
commit adopts a technique similar to the recent Wayland frame sync
changes, except that we enforce a minimum of 33ms between frames
in our own scheduler to avoid blocking for several ms at a time.
This seems to do a decent job of balancing responsiveness during
selection with updating the display, and keeps the buffer swap
delay down to microseconds.
We may want to make this delay configurable.
* WIP: IME support for X11
* Handle text generated by IME.
* Set IME position according to the cursor position.
* Improve IME position handling.
Geometry as well as window focus changes are now handled.
* Dispatch IME strings like it's done on windows.
* Make sure not to silently drop IME errors.
* Respect `use_ime` configuration.
* Add xcb-util as dependency.
* Only update IME position if necessary.
* Formatting.
* Update xcb-imdkit-rs.
* Set IME position under the start of the cursor.
This seems to be the way it is commonly done among gui frameworks.
(Tested with Firefox for GTK and Konsole for QT).
* Update xcb-imdkit-rs.
* Handle systems only providing libxcb-util0-dev.
* Add libxcb to freebsd dependencies.
Required by xcb-imdkit-rs.
* Update xcb-imdkit-rs.
* Try to use more recent gcc on centos7.
* More recent C++ compiler on centos7 as well.
* Also setup correct env on centos7 for tests.
This makes the comparison in https://github.com/wez/wezterm/issues/544
work for me on mac, linux (x11, wayland) and also on Windows but
only using WGL.
It looks like we can use the proper colorspace on all targets
except for ANGLE EGL. For whatever reason, the combination of
glium and ANGLE EGL on windows over-gamma corrects.
AFAICT, the framebuffer and perhaps the surfaces it creates
don't indicate srgb support, and whatever combination of status
they return tickles glium's srgb stuff the wrong way.
I think the "solution" is just to directly use WGL by default.
EGL was on by default because it tended to be more survivable
when graphics card drivers were updated, but the last couple
of times I updated mine it still killed wezterm anyway.
refs: #544
This commit annotates fonts with a boolean that indicates whether
we think it contains glyphs with emoji presentation, and then
passes the cluster.presentation field down to the shaper.
If the presentation doesn't match the current font in the fallback,
then it will be skipped until we exhaust its options.
`wezterm ls-fonts` also shows whether we think a font has emoji
presentation.
refs: #997
This replaces the slightly gnarly subpixel enabled blending in the
shader with Dual Source Blending, which is a technique where the
fragment shader can specify both the primary color (RGBA) as well
as an additional per-channel mask that can be used to alpha blend
with the destination.
This enables artifact-free alpha blending when used together
with a transparent window background.
refs: https://github.com/wez/wezterm/issues/932
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.
