weirdly, BOOL is considered bool when I compile locally,
but in the CI:
```
error[E0308]: mismatched types
--> window/src/os/macos/connection.rs:170:22
|
170 | let max_fps = if has_max_fps {
| ^^^^^^^^^^^ expected `bool`, found `i8`
```
I can't explain the difference in behavior (feels like a compiler
bug?) but let's try comparing explicitly against YES
Use the font height as the basis for the size, rather than the width,
to avoid the buttons being too condensed.
Explicitly use the pixel height for the dimensions so that the
buttons are square.
refs: https://github.com/wez/wezterm/issues/2399
The prior mutually exclusive behavior kept surprising people so let's
just flip this around.
This is potentially a "breaking" change for folks, but I think it is
worth it.
d2892c6 switched to using recency only, but neglected to verify that
the edges of the candidate panes were actually touching, leading to
some weird results.
This commit uses recency only when the edges intersect, otherwise,
scores 0 for the candidate.
refs: #2374
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
