This slightly improves the startup time of wezterm.
Right now we query the portal appearance value again over dbus every
time that we access it, for example every time that the user calls
wezterm.gui.get_appearance() from the Lua interface.
Queries over dbus are slow, they usually take a few milliseconds to
complete, for example on my system a portal query over dbus takes around
2 milliseconds to complete.
Wezterm also automatically calls the portal during its own internal
x11/wayland connection initialization, thus right now wezterm queries
the appearance portal setting n+1 times on startup, where n is the
number of times that the user calls get_appearance() from the config.
To fix this problem, we simply cache the portal appearance.
Thus this patch decreases the startup time by 2ms for users that
configure wezterm to follow the global system theme and potentially by
more for users that call get_appearance() in inflational amounts.
With the naive implementation wezterm would be subject to the following
race condition:
1. wezterm calls get_appearance() and caches the value
2. System-wide dark mode changes
3. wezterm subscribes to portal notifications
In that scenario wezterm would miss the dark mode switch entirely and
would cache the wrong value until the dark mode switches again after
wezterm subscribed.
To fix this race condition we call read_setting() again **after** we
have subscribed just to be on the safe side.
Note that while this still introduces a second "redundant" dbus query
for the same value, this time it does not actually block start up since
it happens in another thread.
refs: #2258
I was seeing a black "hole" in the center of this gradient:
```
background = {
{
source = {
Gradient={
colors = {"rgb(45,26,109)", "black"},
orientation = {
Radial={
cx = 0.75,
cy = 0.75,
radius = 1.25,
}
},
}
},
width="100%",
height="100%",
},
```
setting noise=0 "fixed" it, so this commit localizes that fix
to the center of the gradient by preventing noise from wrapping
around the gradient.
e6421d1b72 removed this bit from the
example:
```
-
- // Note that we're waiting until after we've read the output
- // to call `wait` on the process.
- // On macOS Catalina, waiting on the process seems to prevent
- // its output from making it into the pty.
- println!("child status: {:?}", child.wait().unwrap());
```
This commit revisits that and puts in place a differently horrible
solution for macos.
The issue is that if we don't put in a short sleep on macos, then
for a short lived process like `whoami` in this example, we end up
reading output like this:
```
; cargo run --example whoami
Compiling portable-pty v0.8.0 (/Users/wez/wez-personal/wezterm/pty)
Finished dev [unoptimized + debuginfo] target(s) in 0.60s
Running `/Users/wez/wez-personal/wezterm/target/debug/examples/whoami`
child status: ExitStatus { code: 0, signal: None }
output: \r\n^D\u{8}\u{8}wez\r\n%
```
where the EOT that we send on Drop somehow gets *prepended* to the output
that we read from the pty with a couple of BELs thrown in.
I'm not sure WTF is happening on macOS for that to occur; feels like
some kind of race wrt. process startup and initializing the pty in the
system.
The reader has to be started before we close it as well, otherwise
the same issue can occur.
This breaking API change allows us to explicitly generate EOF when the
taken writer is dropped.
The examples have been updated to show how to manage read, write
and waiting without deadlock for both linux and windows.
Need to confirm that this is still good on macOS, but my
confidence is high.
I've also removed ssh2 support from this crate as part of this
change. We haven't used it directly in wezterm in a long while
and removing it from here means that there is slightly less code
to keep compiling over and over.
refs: https://github.com/wez/wezterm/discussions/2392
refs: https://github.com/wez/wezterm/issues/1396
I'd forgotten that this was in here.
The recentish fixes to flush for various terminal queries
likely need this to be 100% good. Surprised this hasn't
come up as a bug already :-/
`wezterm start -- /etc/profile` would crash on macOS because
`/etc/profile` isn't executable.
This commit checks for executable access as a prereq for both the
path search and the absolute path cases and generates a non-crashing
error:
```
$ wezterm start -- /etc/profile
17:24:03.574 ERROR wezterm_gui > Unable to spawn /etc/profile because it doesn't exist on the filesystem or is not executable (EACCES: Permission denied); terminating
```
I think I may have inadvertently changed whether the arch portion
was included in the filename for stable releases.
Allow for that in the regex.
Remove debian 9 which is no longer supported.
closes: https://github.com/wez/wezterm/issues/2382
They pass this:
```
flatpak run --env=G_DEBUG=fatal-criticals org.freedesktop.appstream-glib validate assets/wezterm.appdata.xml
assets/wezterm.appdata.xml: OK
```
but break when building a flatpak
Previously, we'd unconditionally enable dual source blending for the
text foreground layer when rendering. That meant that if the user had
configured the fg color to include an alpha value it would get "stamped
through" the draw all the way to the background, making that whole pixel
take on that alpha value rather than allowing it to blend through the
way you might expect.
In prior releases that didn't matter, but since we now allow configuring
the fg color with alpha, and allow using escape sequences to set the fg
for a span to something with alpha, there is now a much higher chance of
something looking weird.
Dual source blending is only really needed for subpixel-aa and that
isn't enabled by default.
This commit changes the behavior to use regular alpha blending if the
main config (rather than a per-font override) hasn't set the freetype
load/render target to one that enables subpixel-aa.
That means that alpha channel values work as expected for fg color
by default.
If you want to enable subpixel-aa you need to enable it globally
and be aware that it will cause weirdness when trying to use alpha
channels for the fg text color.
The docs now also indicate this behavior.
This limitation could be removed by making text rendering significantly
more complex and I don't fancy doing that at this time.
