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
This commit safely registers key equivalents with the menubar. Safe in
this context means "doesn't override a key assignment from a key table".
For example, it would suck to define an application-wide key assignment
for a key combination that has a different assignment in a key table
that may be activated conditionally by some user-defined state/mode.
refs: https://github.com/wez/wezterm/issues/1485
This allows defining those help actions that open URLs in the main
commands list, and not just for the macOS Help menu.
refs: https://github.com/wez/wezterm/issues/1485
This took a decent amount of effort to thread through with context;
wrappers around NSMenu and NSMenuItem are added to reduce some of
the objc usability warts, and an additional NSObject wrapper is
added to help copy the KeyAssignment from the existing list
of command palette commands and associate it with the menu item.
When a menu item is selected, macOS will walk through the responder
chain and look for a responder that responds to the selector associated
with the menu item. In practice that means that our window/view class
will be tried first, and then later, our app delegate will be tried.
This commit implements routing from both of these: the window case
routes to the associated TermWindow and drops into the existing
perform_key_assignment method.
In case there is no window (not currently possible, but will be
in the future), the app delegate also has a placeholder for dispatching
key assignments, although it will only be able to perform a subset
of the possible actions.
A couple of things to note:
* Items aren't smart enough to disable themselves or adjust their
caption based on the context. To make that work, we either need
to recreate the entire menubar when any possible context changes
(doable, but feels heavy), or we need to assign a target to each
menu item and implement a validation handler on that target.
That seemed to mess with the responder chain when I briefly
experimented with it.
* There's some disabled code to add a Services menu. It is disabled
because when it is enabled, accessing either Services or Help
from the menu bar sends the process into a busy loop somewhere
in macOS's internals. It's unclear what it is unhappy with.
* No keyboard accelerators are associated with the menubar yet.
That needs some thought, as they would essentially become global
keyboard shortcuts and take precedence over the shortcuts defined
for other keys in the config. This feels like it should be something
that the user has control over, so there needs to be something to
allow that before we go ahead and wire those up.
refs: https://github.com/wez/wezterm/issues/162
refs: https://github.com/wez/wezterm/issues/1485
Implement an app delegate to receive a callback when the system
requests that we open `.command` files, and then ask the mux
layer to spawn a window for it and execute it via the shell.
Also allow handling `.sh`, `.zsh`, `.bash`, `.fish` and `.tool`,
per kitty.
refs: https://github.com/wez/wezterm/issues/2741
refs: https://github.com/wez/wezterm/issues/2871
https://github.com/wez/wezterm/pull/2435 proposed including
CTRL-modified keys, but I think that the state of the code now means
that we can simplify that area and adjust it so that we will default to
routing keys to the IME, but excluding them based on the
`send_composed_key_when_(left|right)_alt_is_pressed` configuration.
I've only very lightly tested this, but it seems ok with roman text and
me punching in random pinyin and then using CTRL-H or CTRL-M to delete
or enter.
refs: https://github.com/wez/wezterm/pull/2435
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
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
Right now the initial x11 appearance retrieval uses the specific
connection interface, which completely circumvents the already existing
more complete implementation in x_and_wayland.rs.
The latter implementation is strictly better, because it first attempts
getting the appearance from the XDG desktop portal and then falls back
to the X11 interface.
Before this patch there was a very weird issue for folks using the OS
system dark mode with the following config snippet:
```
color_scheme = scheme_for_appearance(wezterm.gui.get_appearance())
```
The color_scheme on startup would be correct, but there would be a very
weird problem where sometimes wezterm ignores the first time that the
portal notifies about an appearance update.
The source of the bug was an inconsistent retrieval of the appearance
setting:
- The Lua API used the XDG desktop portal
- The internal appearance used the X11 specific connection at startup
For example due to this, the internal appearance variable could have
stored "Dark" from the X11 connection, but the actual appearance from
the XDG desktop portal was "Light".
If then the XDG desktop portal changes to "Dark", the
appearance_changed() method would dismiss the update because
self.appearance was already "Dark".
It is only after that, that the internal inconsistency would have been
solved and following appearance changes would succeed and update the
colorscheme correctly.
To fix this problem, we now use the portal directly in both the x11 and
wayland connections, which is consistent with the Lua
wezterm.gui.get_appearance() API.
refs: #2258
Querying the window can call into windowproc so we need to avoid
it when we hold `inner`. Adjust the flow so that we can get
the info about the window state purely from an HWND.
refs: #2257
Since applying the maximized state is async, we hadn't fully applied
it before we got to the startup logic that resizes the window to fit
the initial terminal size.
This adds a final check to see if we are resizable before we try
to apply that size, and skips it.
refs: #284
Hook it up for resolving geometry, but note that wayland doesn't
allow positioning and we don't expose a way to set width/height
based on screen right now.
On Windows, GDI returns unintuitive names like "\\.\DISPLAY6" that
may not start numbered at either 0 or 1.
This commit grubs through the various APIs so that we can produce more
meaningful names like "DISPLAY6: Gigabyte M32u on NVIDIA 2080 TI"
instead.
This commit also makes the lua wezterm.window.screens() function
consistent with the internal resolve_geom functions that each different
implementation had, so that we can eliminate those functions in
favor of this new one on the ConnectionOps trait.
Still need to do macOS and verify that this commit doesn't break X11.
Currently implemented on X11 only, this function returns information
about the geometry of the screen(s).
This is taken from the same source of information we use for the
`--position` CLI argument to `wezterm start`.
```
> wezterm.window.screens()
{
"by_name": {
"DisplayPort-1": {
"height": 2160,
"name": "DisplayPort-1",
"width": 3840,
"x": 0,
"y": 0,
},
},
"main": {
"height": 2160,
"name": "DisplayPort-1",
"width": 3840,
"x": 0,
"y": 0,
},
"origin_x": 0,
"origin_y": 0,
"virtual_height": 2160,
"virtual_width": 3840,
}
```
This is a bit of an unsatisfactory commit... the bulk of it is
augmenting our calls into XCB to ensure that we check the status of each
request; the idea was that doing so would highlight the source of the
bad drawable error that is being surfaced in #2198, but after doing
that, it still doesn't highlight the offending call.
My conclusion is that either something in MESA/EGL or the IME is
generating calls that we cannot see into and that one of those is
referencing the window id that we just destroyed.
The resolution then is a bit gross: instead of destroying the window
when we need to close it, we first unmap it to remove it from the
screen, then after 2 seconds we destroy it.
refs: https://github.com/wez/wezterm/issues/2198
This commit adds more trace logging around selection
related events.
That tracing uncovered a situation, when multiple wezterm windows within
the same process were involved, where one window didn't receive a
selection-clear event notification.
Since Window::get_clipboard trusted our local understand of the
clipboard contents, it would return those until the selection was
changed in that window.
This commit changes that code to always ask the X server for the
selection. It makes pasting slightly slower, but should always produce
consistent results.
refs: https://github.com/wez/wezterm/issues/2110
deadkeys that are triggered through shift (eg: backtick on a German
layout) weren't working because we were trying to lookup in our maps
using `SHIFT | LEFT_SHIFT` when the map data was keyed only by `SHIFT`.
This commit removes the positional modifier flags from the modifier
keys and restores the correct behavior.
refs: https://github.com/wez/wezterm/issues/2102
This does two things:
* Sets the event queue owner explicitly to xcb
* Adopts a dri2 resize related workaround from the rust-xcb opengl
example
I think the latter is probably a NOP, but the former sounds like
something important.
refs: #1992
Adds a configuration option, `focus_change_repaint_delay` to allow customisation of the delay added in 9b6329b454.
The default delay remains 100ms, and can be disabled by setting it to `0`, if the workaround is not required on the user's system.
refs: #2063
refs: #1992
The hope here is that the nvidia-specific resize issue might have
a workaround if it is emitting some other events that we were
previously not listening for.
This commit optionally enables the Present extension and listens
for its version of CONFIGURE_NOTIFY, routing it through the same
logic as the base CONFIGURE_NOTIFY event.
On my AMD hardware under Gnome, I see something like:
```
18:04:26.476 TRACE window::os::x11::window > Present::ConfigureNotify: width 1168 -> 1180, height 858 -> 873, dpi 124.7998046875 -> 124.7998046875
18:04:26.478 TRACE window::os::x11::window > Ignoring X::ConfigureNotify (1180x873 dpi=124.7998046875) because width,height,dpi are unchanged
```
with the Present event firing before the X event.
Let's see how this goes.
refs: #2063
refs: #1992
Main idea here is to add expose events to the trace so that we
can get a sense of whether those are emitted when a WM isn't delivering
CONFIGURE_NOTIFY consistently.
If the exposed area is bigger than what we think the window is,
then we mark geometry as unsure.
I'm considering always marking as unsure for an expose event,
or at least, adding a config option to enable that, as a way
to workaround this situation.
refs: https://github.com/wez/wezterm/issues/2063
refs: https://github.com/wez/wezterm/issues/1992
This commit:
* Logs atom names in property change events (makes it easier to
understand user's logs)
* Sets flags in cases where property changes might imply that a
configure or focus event should have or should be sent
* Adjusts the "unsure about state" logic so that it doesn't just
trigger on the initial paint, but also on those flags being set
refs: https://github.com/wez/wezterm/issues/1992
I think this might only be a thing on Windows.
This commit speculatively (I'm on a mac at the moment!) allows tracking
the left/right control/shift modifier flags and passing that through
to the win32 input mode logic.
refs: https://github.com/wez/wezterm/issues/2009
