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.
Not sure what happened here: presumably a borked merge or something
similar, but this commit allows `window:get_appearance` to return
the actual appearance value on X11.
Even though this plumbs the call through to Wayland, Wayland doesn't
provide an equivalent concept so still always return Light, as is
mentioned on our docs.
closes: #1098
* Trigger a paint immediately from invalidate if not throttled
* Otherwise defer the other events until we're about to sleep for xcb
events, which should maximize the coalesce around resize/expose events
refs: #1051
The thesis is that some WM's might send a whole bunch of events
that cause us to over draw/over resize.
I'm not convinced that this is a righteous change, but it can't
hurt to try.
refs: #1051
Some users mentioned that there's a lag after selecting text
on X11. Tracing through, I saw that the we invalidate the window
quite a lot when dragging the selection, and the buffer swap could
delay for several ms each time while waiting for the vsync.
Rather than blocking the GUI thread and making it bog down, this
commit adopts a technique similar to the recent Wayland frame sync
changes, except that we enforce a minimum of 33ms between frames
in our own scheduler to avoid blocking for several ms at a time.
This seems to do a decent job of balancing responsiveness during
selection with updating the display, and keeps the buffer swap
delay down to microseconds.
We may want to make this delay configurable.
