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
