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
When we translate a dead key, send the composed event immediately
and don't try to route the current key press via the IME.
Improve rendering when in the composing state: overlay the composing
text at the cursor position to show what the composing text would
look like, even though it hasn't been committed to the input stream
yet.
refs: https://github.com/wez/wezterm/issues/1504
For Korean text input, pressing SHIFT and then typing in certain
keys begins a composition sequence. Our logic for when to route
via the IME got so distracted by ALT that it didn't consider SHIFT
and didn't send this sequence to the IME, so we'd fail to compose
those sequences.
While poking at this, I realized that we should treat this composition
similarly to dead keys, in that we can signal the term window to
highlight the cursor color and report that status.
There's some further work to do: the composing text should be rendered
by us. So far our IME integration assumes that the IME itself will
render over the top of our window, but for this particular input
it doesn't do that.
refs: https://github.com/wez/wezterm/issues/1504
Since we now have RawKeyEvent and a sane way to indicate handling,
we don't need these any more, and it simplifies key dispatch to
remove them.
refs: #1483
Pass down whether we are in a live resize to the gui layer, so that
we don't incorrectly assume that the scale has changed, and fight
with the window manager.
Built this on my mac: will need to fixup for windows and linux.
refs: https://github.com/wez/wezterm/issues/1491
This moves the event dispatching into the keyboard processor,
which will allow for the processor to skip feeding an event
into the dead key/composition stuff if a key assignment is
handled.
It doesn't actually do that bit yet though, as the wayland
key repeat processing was a bit more involved and I wanted
to constrain the scope of this commit.
refs: #877
on macos only (for now), we generate a RawKeyEvent prior to
dead key or IME composition and route it to the window to give it
a chance to handle the event.
RawKeyEvent handling is scoped only to key assignments, not generating
input for the terminal.
A raw key event can be marked as handled to prevent moving on to
performing composition and generating cooked key input.
refs: https://github.com/wez/wezterm/issues/877
Previously, we'd take a couple of guesses at how to map the key
to a utf8 value, but! the keyboard state has a method that can tell
us what to use.
This is important in non-latin keymaps where, for example, the `c`
key generates cyrillic small letter es and we'd end up sending
CTRL + that through to the terminal when CTRL is held down.
If we get the utf8 string from the keyboard layer then we get
CTRL+c instead, and that is what we want.
refs: https://github.com/wez/wezterm/issues/678
I saw this when the IME was active:
```
2021-12-31 00:46:26.941 wezterm-gui[46160:16665949] -[NSConcreteMutableAttributedString UTF8String]: unrecognized selector sent to instance 0x600002b24180
```
the issue is that some of the window callbacks can receive either
NSString or NSAttributedString. The latter doesn't have a UTF8String
method, but does have a string property that returns an NSString
that can be used instead.
Certain keys are "handled" by the IME through it generating a "noop"
command.
That's not super useful for us, so this commit detects the noop case
and then treats it as though the IME didn't handle the input event.
While implementing the above fix, I realized that the same technique
could be used more generally to return processing to our main input
handling for the various selectors that we do recognize: we were
essentially inferring the original key combinations based on the
selector which is not scalable and potentially lossy.
We can't capture CTRL-ESC this same way, as that key combination
is magical and is routed to the callback without generating any
key events.
refs: https://github.com/wez/wezterm/issues/615
refs: https://github.com/wez/wezterm/issues/975
refs: https://github.com/wez/wezterm/pull/1410
This commit adds a CSS box model inspired element / layout
facility, and replaces the hand implemented fancy tab bar
element render.
This makes the code for fancy tab bar much easier to read
and update.
The right status area now expands to the full height of the
tab bar area, and uses a line height of 2.0, which makes
it line up nicely in the tab bar.
On Windows, both EGL and MESA render modes were too dark.
After a bit of hunting around what I found made EGL and MESA
consistent with my default nVidia GPL rendering was:
* Tell glium that our shader outputs srgb
* Add explicit gamma conversion from linear to srgb in the shader
AFAICT, that shouldn't be required, but it seems as though something
deep in glium really wants to apply some kind of gamma conversion,
and it seems to select the wrong kind unless we set things explicitly
to SRGB.
There are some people complaining about this in
https://github.com/glium/glium/issues/1615.
I actually tried to move entirely aware from the glium srgbtexture2d
type in the hope of having explicit control over the gamma, but the
issue is in what happens to the outputs rather than the inputs.
It appears to me as though the text now looks slightly less
intense, so I think this may be what we need for the gamma issue
in https://github.com/wez/wezterm/issues/544 and potentially
also https://github.com/wez/wezterm/issues/1025
refs: https://github.com/wez/wezterm/issues/1373
In the worst case this can cause badly implemented desktop components like panels
to constantly rerender and waste 100% CPU (that's how I found a bug in mine :D)
when anything is constantly updating in the terminal (like viewing a log stream).
When using client-side decorations, we can now skip rendering
the header/title bar.
If you've set NONE decorations, then wezterm will configure
the window that way, but that is only respected when the window
is created, as weston crashed when I tried to change this in
a window config reload event.
The wayland frame now also observes config change events,
so frame color adjustments should now take effect without
restarting.
refs: #1077
Changing surface configuration flags *to* default would never be applied.
This was uncovered when implementing increment step resize: it would stop
working after *one* maximization.
The wl_keyboard definition does not define that the incoming fd is always at seek position 0.
In fact, the spec says the fd "can be memory-mapped" and that's it.
And e.g. smithay client-toolkit uses mmap, but we don't :/
Use pread() to read from zero.
This commit introduces a mechanism for specifying resize increments
for a window, and then arranges for the termwindow to set those
to match the current font cell metrics.
This should help to avoid cases where there is excess padding pixels
resulting from the window being slightly larger than computed number
of cells and the font metrics.
