The warning is that some of the variants are never read.
In the case of ftwrap, they are referenced via ffi.
For the other locations, we want them for debug purposes.
Error message I've been seeing the past couple of days:
Unable to resolve appearance using xdg-desktop-portal: invalid value:
string "()", expected at least one field signature between `(` and `)`:
invalid value: string "()", expected at least one field signature
between `(` and `)`
The upstream open crate keeps making stuff async/blocking/not-working on
windows, so this is a step towards removing this dependency.
refs: https://github.com/wez/wezterm/issues/3288
We were only using block_on from it, which we can call from the
underlying async_io crate.
Notably, removing async_std from the deps avoids async-global-executor
being pulled in and spawning nproc threads that are never used by
wezterm.
Otherwise we can block the gui waiting for eg: a freshly opened firefox to
terminate.
See also comment worrying about this in
75066cb522.
That fear was realized but now resolved!
refs: https://github.com/wez/wezterm/issues/2245
Main thing to note here is that the open crate has deprecated
open::that_in_background, but made open::that non-blocking.
I think this is OK, but I'm a little cagey about what will
happen with this on Windows. We may need to spawn our own
thread for this if things go awry.
The `open` crate blocks forever when spawning the browser via xdg-open,
which feels kinda "wrong" to me, but does offer a method that can stick
that in a background thread, so that's what we do here.
refs: #1721
It appears as though Menlo is the only font on macos to contain the
heavy ballot cross symbol, which is commonly used on macos (eg: in
`brew` output).
Our fallback list, despite starting with Menlo, didn't include menlo
itself in the candidates.
Furthermore, `ls-fonts` wouldn never see the result of the system
fallback resolution because it didn't know to try again, and was
using the list of handles from before the fallback.
This commit resolves all of these concerns.
refs: #849
I've built this on linux, which doesn't respect the timeout.
I've made speculative changes that should build on mac and windows,
but that don't plumb the timeout functionality on those systems
as of yet.
refs: #619
Replaces notify-rust with directly calling into the zbus crate.
This provides a pure rust interface to DBUS and provides more
flexible control over notification handling.
closes: #485
This commit implements the deprecated NSUserNotification bits needed
to be able to handle clicking on a notification and open our choice
of URL.
Ideally we'd use the newer UserNotifications framework, but that
requires code signing.
* Allow injecting some initial output to new panes
* Have the update checker set this new-pane-banner to a short
upsell to let the user know there is an update.
* Refactor toast notifications into their own crate
* Have the update checker call a new stub function that triggers
a toast notification with an URL... but it does nothing because
the rust ecosystem doesn't support this on macos yet and I'm
writing this code there
