We want to avoid normalizing control key presses; there were
two places where it was happening; one in our own code and
the other was in the xkeyboard mapping stuff itself.
refs: https://github.com/wez/wezterm/issues/1851
There are certain key combinations that macOS prefers to handle
without giving the application much opportunity to process them.
CTRL-ESC and CMD-. both cause doCommandBySelector(cancel:) to be
called. The former we had already special cased but since we
can't disambiguate the two things, we need a better way.
performKeyEquivalent: is a method we can implement to have an
opportunity to "do something" and prevent the default macOS behavior.
So we implement that. What's interesting is that saying that we handled
CMD-. results in no further processing at all by macOS, whereas saying
that we handled CTRL-ESC results in macOS doing the normal key event
dispatch. So we need to route that event for ourselves in that one
case.
Doesn't feel great!
refs: https://github.com/wez/wezterm/issues/1867
Go directly to the underlying env_logger crate, as pretty_env_logger
hasn't been updated in some time, and I'd like to be able to redirect
the log output to a file more directly, and that feature is in a newer
version of the env logger than pretty_env_logger was pulling in.
For reasons that I cannot remember, I made
`send_composed_key_when_left_alt_is_pressed` and
`send_composed_key_when_right_alt_is_pressed` only take effect if only
the ALT modifiers were pressed. If SHIFT or CTRL were pressed, then
the purpose of `send_composed_key_when_left_alt_is_pressed` was
bypassed.
This commit scopes this back to the alt mods - other kinds of mods
don't affect this functionality any more.
refs: https://github.com/wez/wezterm/issues/1826
We were pinned on the revision where I had added dual source blending,
because I wanted that feature ahead of the crate being published.
Since then a couple of releases have been made so we can unpin.
On Windows 11, we had a report of glium complaining about the opengl
version. I can't find that error message string in the current version
of the code so it's possible that that situation has been resolved.
refs: https://github.com/wez/wezterm/issues/1813
This is mostly a refactoring: pulling out the discrete width/height from
the `new_window` method and preparing to pass down x/y coords as well.
The types are expressed as Dimension so that screen relative sizes could
be expressed in the future... once we know how to obtain that
information on each platform.
refs: https://github.com/wez/wezterm/issues/1794
- Simplify scroll thumb calculations
- Correct thumb position when dragging with mouse
- Support border OS parameters
- Use usize for OS borders, to explicitly only accept positive integers
- Get correct tab height when using fancy tab bar
- Correctly draw depending on tab bar position
- Adjust minimum thumb size to be 1/2 of a cell height, so it has consistent size across platforms and screen densities
Fixes#1525
We don't assume that we start up focused, and some WM don't tell
us our focus state, so prior to painting, if we don't know the
focus state, explicitly query it and synthesize a focus change event.
refs: https://github.com/wez/wezterm/issues/1757
Flesh out the get_os_parameters impl for macOS. When running on a
system that provides `NSScreen::safeAreaInsets`, use that to determine
the border required to avoid the "notch" on certain models of mac.
In the GUI layer: when the os parameters include a border, adjust
the render position to account for it.
This is a bit of a speculative change, as I don't have a mac with
a notch.
refs: https://github.com/wez/wezterm/issues/1737
If the WM has never confirmed our size and we're about to paint,
explicitly query it and generate a resize event so that we stand
a better chance of showing the right stuff.
refs: https://github.com/wez/wezterm/issues/1710
When the user switches to another virtual console and then back into a
Wayland session, a number of seat updates are received by the listener
installed by `Environment::listen_for_seats()`. These updates
essentially flip the keyboard and pointer flags off and then back on in
the seat data, which indicates that new handlers need to be assigned to
the keyboard and pointer objects.
However, because one update is received for _each_ flag being toggled,
this means that the listener is fired twice with `has_keyboard` set to
true, which means that two keyboard handlers end up being installed.
Users then experience each keypress being delivered twice to the
terminal.
This commit adds a map to track the keyboard object that has been
assigned on each seat, thereby preventing duplicate assignments and (by
extension) duplicate keypresses being registered. This logic is
essentially the same as what's used in the `kbd_input` example in SCTK,
which doesn't have this issue.
Something similar is required for pointer handling, which also breaks
after switching to another virtual console and back into Wayland, but I
was scared off by the TODO in the `listen_for_seats` callback and didn't
investigate this further.
On Windows in FRA layout, `^^SPACE` results in `^^SPACE`, whereas
on Linux it results in `^SPACE`. We were doing the latter instead
of the former.
Let's just be consistent with other windows apps.
closes: #1729closes: #1730
