Weird behavior from macos; the command line:
`wezterm start vim hello`
would result in macos requesting `vim` and `hello` be opened
as "documents" which would route each of those to the .command
script handling flow and spawn a window for each; running:
`vim ; exit` in one
`hello ; exit` in another
in addition to the normal handling of that command line.
This commit resolves this by igoring document opening
requests until after the application is fully launched.
I tested this by trying to open a .command script with
this new build and verified that that continued to work.
refs: #3340
- Removes closures and function calls for types that implement default:
```rust
// Change
let _my_str = get_str().unwrap_or(String::new);
// To
let _my_str = get_str().unwrap_or_default();
```
- Uses the `.cloned()/.copied()` methods where possible
- Use function pointer instead of simple closure
May improve performace, as closures generate more code, and this might
unlock some inlining opportunities.
- Use `find` instead of `position(..).next()`
- Use `any` instead of `position(..).next().is_some()/.is_none()`
- Use `first/next` instead of `get(0)/nth(0)`
- Prefer `for` loops over `while let` loops on iterators
May improve performance.
A user reported this:
08:47:13.372 DEBUG window::os::x11::connection > Unable to
resolve appearance using xdg-desktop-portal: Read:
org.freedesktop.DBus.Error.TimedOut: Failed to activate service
'org.freedesktop.portal.Desktop': timed out
(service_start_timeout=120000ms)
which is an issue with their xdg-portal service.
Rather than have wezterm block for 2 minutes on startup, we give it
1 second, and log the issue as a warning.
If there are no windows, clicking on the dock icon will spawn a new
window.
Requires that `quit_when_all_windows_are_closed=false`
refs: https://github.com/wez/wezterm/issues/3057
The recently added app delegate was telling cocoa that we'd decide
to quit later in response to termination requests, blocking
shutdown/logout/restart.
This commit introduces a macos native modal alert to let the user
decide whether to quit or not.
While testing this, I noticed that in some cases, our internal choice
to quit had no effect. Reading the fine print of NSApp::stop, it sounds
like calling it from a modal context will only stop a modal rather then
exit out of NSApp::run, so we explicitly bounce through an event
callback to try to make it exit from the right place.
I'm not 100% convinced by this. I've left some debug prints in for
now to see if those give some insight in the future.
refs: https://github.com/wez/wezterm/issues/2944
This is moderately painful to do, because of some objc/cocoa lifetime
concern that causes a crash when attempting to simply replace the
entire menubar, so we try to find/update items instead.
refs: https://github.com/wez/wezterm/issues/1485
