The upgrade to a newer mio version caused the poll method
to report EINTR in some cases.
We don't need to terminate for those, so suppress it.
refs: https://github.com/wez/wezterm/issues/1955
a redo of 81d08325c1, which was a bit
more nuanced. Partially revert the logic from that commit and rephrase
it as factoring out the condition to make that part clearer, but restore
the original action, which is important in order to propagate the
modifiers through.
refs: https://github.com/wez/wezterm/issues/1907#issuecomment-1108797343
I think I'd like to make a config option for this, but for the moment,
this first pass unconditionally updates the base environment with
data from the registry.
refs: https://github.com/wez/wezterm/issues/1848
Looking closer, I think I'd misread the key event generated by
perform_key_equivalent for the ctrl-escape case as a key down.
Fixing this is fairly straightforward: when we return YES from
perform_key_equivalent we synthesize a key_down event.
macos will follow up with the key up.
We can fold two cases together in there and remove the horrible
hack style fix I just added in a4b68247bb
refs: https://github.com/wez/wezterm/issues/1877
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
* Detect mouse leaving the window
* Implement leave
* Use new API
* Fix mouse leave
* Fix mouse leave on Wayland
* Mouse leave on X11
* Detect mouse leaving window on macOS
* Fix example
refs: #1434
This might "break" eg: pasting from apps that just use ATOM_STRING
and that happen to have utf-8 compatible text.
Ideally the get_text_property interface would expose the actual
text encoding in the returned data and allow the application to
"do stuff" with it.
refs: https://github.com/meh/rust-xcb-util/issues/21
Resolves a little bit of the awkward duplication of color types
between some of the crates by factoring them a little bit better.
This is prep for allowing specifying alpha for some colors
in the config.
This puts to final rest #478, wherein ligatured glyphs that span
cells would render portions of the glyph with the wrong fg color,
where wrong was usually the bg color and cause the glyph to turn
invisible when cursoring through the ligature.
The approach used here is to divide the glyph into 7 discrete strips
where each strip either intersects with the cursor, the selection, or
neither. That allows us to render each strip with the appropriate
foreground color.
This change simplifies some of the logic and allows some other code
to be removed, so that feels good!
As is tradition with these renderer changes, there's a good chance that
I overlooked something in testing and that the metrics or alignment
might be slightly off for some font/text combo. Let's see how this
goes!
refs: #784
refs: #478
refs: #1617
This allows unicode_version to be respected again when rendering.
The updated emoji-presentation.sh script now highlights this slightly
better by putting `.` characters after the emoji; unicode version 14
emoji presentation will show the `.` in the 3rd column, while earlier
versions will show it in the 2nd column for glyphs that are sensitive
to the version.
refs: #1607
refs: #1563
This action causes the active workspace for the gui to change.
If the name is omitted a random name will be generated.
If the workspace doesn't exist, it will be be created.
The optional spawn parameter can be used to launch a specific
program into the new workspace; if omitted, the default prog
will be used.
The gui only supports a single active workspace. Switching workspaces
will repurpose existing gui windows and re-assign them to windows
in the new workspace, adjusting their size to fit those windows,
spawning new windows or closing unused windows as required.
The gui now exits when there are no panes in the active workspace,
rather than no panes at all.
refs: #1531
When a dead key is composing, we gave no information about what was
composing. Contrast with Windows and macOS where we show the first
key in the composition as part of that state.
This commit makes an attempt to populate equivalent information.
It's a bit more complex with the xkeyboard stuff as there can be
multiple combining sequences and there's no guarantee that we can
show a meaningful label.
We try our best for the common case of a single dead key, and have
a probably reasonable fall back for other cases where we don't
other get that information.
This allows removing DeadKeyStatus::Holding.
lalt-` is technically a dead key combo, so we entered dead key
processing, then realized that
`send_composed_key_when_left_alt_is_pressed == false` and that
we should ignore the dead-key-ness of the combo, but returned
a composed result, which had the modifiers discarded.
The correct way to handle this is to signal that it wasn't
dead after all and to allow the main flow to build the KeyEvent
as normal.
We need 100% of the info for it to work correctly, so this commit:
* Exposes the keyboard encoding mode via the Pane trait
* Adds the scan code to the RawKeyEvent
* Has the GUI perform the encoding if the keyboard is set that way
* Removes the basic encoder from termwiz in favor of the gui level one
The net result is that we bypass the Pane::key_up/Pane::key_down methods
in almost all cases when the encoding mode is set to win32-input-mode.
There is now a config option: allow_win32_input_mode that can be
used to prevent using this mode.
refs: #1509
This commit causes the terminal to emit win32-input-mode encoded key up
and down events for a limited subset of keys When win32-input-mode is
enabled.
We limit them to keys where we know the VK key code equivalent,
and where those keys are either not representable (eg: modifier
only key events), or may generate ambiguous output (eg: CTRL-SPACE
in different keyboard layouts).
However, in my experiments, modifier only key presses confuse powershell
and cause it to emit `@`, so I've disabled that in the code for now.
refs: https://github.com/wez/wezterm/issues/318
refs: https://github.com/wez/wezterm/issues/1509
refs: https://github.com/wez/wezterm/issues/1510
