This adopts a similar technique to that used to pass the wezterm
config to the term crate, but this time it is for passing it to
the window crate.
The use_ime option has been ported over to this new mechanism.
Hooks up toggling fullscreen mode on macos, with plumbing for
other systems.
I prefer not to use the "modern fullscreen" mode because I find
the transition animations in macOS are horrendously slow.
I'll make an option to allow selecting whether that is used or not
in a follow-on diff.
refs: https://github.com/wez/wezterm/issues/177
When we decode a key event from X11 into a `KeyCode::Char(_)` variant,
that result has already factored in the result of the SHIFT modifier
state.
That makes SHIFT largely useless for unicode keys; we do want to
preserve the SHIFT modifier for keys such as the arrow keys.
This commit removes SHIFT from the `KeyEvent::modifiers` for
`KeyCode::Char(_)` variants so that those modifiers don't get
in the way of keymap lookups.
refs: https://github.com/wez/wezterm/issues/394
I didn't recreate precisely the situation in the issue, but I
tried pressing both `AltGr 8` and `CTRL ALT 8` with a DEU
layout active and both now result in `[` being emitted.
refs: #392
Revise logging so that we use info level for things that we want
to always log, and adjust the logger config to always log info
level messages.
That means shifting some warning level logs down lower to debug level so
that they aren't noisy.
closes: https://github.com/wez/wezterm/issues/388
https://wiki.lazarus.freepascal.org/Cocoa_DPI states that the dpi
on macOS is 72. That matches up to the experimental results reported
in #332 (in which 74.0 appears about the right size).
This commit introduces a `DEFAULT_DPI` constant that is set to 72 on
macOS and 96 on other operating systems.
The result of this is that a 10 point Menlo font now appears to be
the same size in Terminal.app and WezTerm.app.
refs: https://github.com/wez/wezterm/issues/332
This commit improves input processing on macOS; passing the keyUp
events to the input context is required for dead keys to correct
process their state transitions.
In addition, we weren't passing key events through if any modifiers
were down; for dead keys we need to allow Option through.
This commit rigs up a little bit of extra state to avoid double-emitting
key outputs from the input context.
Lastly, the virtual key code is passed through to the KeyEvent to
enable binding to raw keys per 61c52af491
refs: #357
This commit is a bit noisy because it also meant flipping the key map
code from using the termwiz input types to the window input types, which
I thought I'd done some time ago, but clearly didn't.
This commit allows defining key assignments in terms of the underlying
operating system raw codes, if provided by the relevant layer in the
window crate (currently, only X11/Wayland).
The raw codes are inherently OS/Machine/Hardware dependent; they are the
rawest value that we have available and there is no meaningful
understanding that we can perform in code to understand what that key
is.
One useful property of the raw code is that, because it hasn't gone
through any OS level keymapping processing, its value reflects its
physical position on the keyboard, allowing you to map keys by position
rather than by value. That's useful if you use software to implement
eg: DVORAK or COLEMAK but want your muscle memory to kick in for some of
your key bindings.
New config option:
`debug_key_events = true` will cause wezterm to log an "error" to stderr
each time you press a key and show the details in the key event:
```
2020-12-06T21:23:10.313Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Char('@'), modifiers: SHIFT | CTRL, raw_key: None, raw_modifiers: SHIFT | CTRL, raw_code: Some(11), repeat_count: 1, key_is_down: true }
```
This is useful if you want to figure out the `raw_code` for a key in your
setup.
In your config, you can use this information to setup new key bindings.
The motivating example for me is that because `raw_key` (the unmodified
equivalent of `key`) is `None`, the built-in `CTRL-SHIFT-1` key
assignment doesn't function for me on Linux, but I can now "fix" this in
my local configuration, taking care to make it linux specific:
```lua
local wezterm = require 'wezterm';
local keys = {}
if wezterm.target_triple == "x86_64-unknown-linux-gnu" then
local tab_no = 0
-- raw codes 10 through 19 correspond to the number key 1-9 positions
-- on my keyboard on my linux system. They may be different on
-- your system!
for i = 10, 20 do
table.insert(keys, {
key="raw:"..tostring(i),
mods="CTRL|SHIFT",
action=wezterm.action{ActivateTab=tab_no},
})
tab_no = tab_no + 1
end
end
return {
keys = keys,
}
```
Notice that the key assignment accepts encoding a raw key code using
a value like `key="raw:11"` to indicate that you want a `raw_code` of
`11` to match your key assignment. The `raw_modifiers` portion of
the `KeyEvent` is used together with the `raw_code` when deciding
the key assignment.
cc: @bew
This allows stashing the raw key identifier from the keyboard layer.
Interpreting this value is hardware and OS dependent.
At this time, only X11/Wayland implementations populate this value,
and there is no way to do key assignment based upon it.
This is basically the same issue as
70fc76a040 but on macOS. Now that we're
using EGL in more places, the same sort of check needs to used in more
places!
Will need to do the same on Windows in a follow-up commit.
refs: #316
Not 100% sure that this is it, but it seems much less likely that
artifacts will appear in conjunction with transparency when the window
shadow effect is disabled; I didn't see the ghosting with this disabled,
but I sometimes dididn't see it with it enabled, so I'm not sure that we
have a 100% reliable reproduction, and thus am not sure that this is a
fix.
I found mention of disabling the shadow in some example code on
stackoverflow when I was first researching this, but it wasn't supplied
with an explanation. Perhaps this is why?
Longer term we might want to be smarter about turning off the shadow
only when the opacity is != 1.0, but at the moment the window layer
can't see the config, so let's just default it off for the moment
until we see if it does the trick.
refs: #310
Wheel events wouldn't get reported to eg: vim in wsl if the
window's X position was larger than the window width due to
mouse wheel messages being reported with screen coordinates
rather than client coordinates.
This commit addresses that.
When allocating space in the texture atlas, we typically use
a small padding to avoid accidentally interpolating textures
into glyphs.
When it comes to rendering images via iterm2 or sixel image
protocols, the image emitted by the user may not exactly fill
the cell dimensions, and due to the how the shader works to
apply those textures we could end up revealing nearby images
in the texture when displaying an unrelated image.
This commit adjusts the texture atlas allocation when making
space for image protocol textures; excess padding based on
an overestimate of the cell dimensions is added to the right
and bottom of the image, guaranteeing that that border will
be filled with transparent pixels.
This is a bit wasteful of texture space, but isn't egregiously
bad and is easy to reason about and makes things look less
janky.
refs: #292
This commit uses the guillotine algorithm to assign rectangles,
which is superior to the dumb algorithm previously in use.
In addition, in the first pass of painting, if we get a texture
space error, we clear the atlas and try again without increasing
it size, which should serve as the ultimate defrag.
Subsequent passes will cause the texture to grow if needed.
refs: #306
This is a bit more involved than I'd like, but it seems more
deterministic than using `TranslateMessage` or `ToUnicode` in all cases.
This commit expands the depth of the keyboard layout probing that
is performed when we detect a changed keyboard layout.
We know detect starting `(Modifier, VK) -> char` for a dead key press,
as well as the map of terminating `(Modifier, VK) -> char` for valid
dead key presses.
This information allows us to simply lookup the mapping without
calling `ToUnicode`. Avoiding `ToUnicode` is desirable because it
maintains a global state and it is unpredictable what else is
manipulating that same state. In particular, for the ESP keyboard
layout where `~` is a dead key that is reached via `AltGr 4`, there
doesn't appear to be a reliable way to extract the correct mapping
from it when calling `ToUnicode` in response to the various KEYUP,
KEYDOWN messages. We could get it if we always called
`TranslateMessage` and only looked at `WM_CHAR`, but that means that
we cannot decompose `WM_CHAR` back to the raw key events when we
need to. Bleh!
Test Plan for this commit:
* With ENG layout active, check that CTRL, ALT and so on have the
intended effect in the terminal; eg: CTRL-C, CTRL-W (in vim).
* Switch to pinyin layout, check that typing still invokes the
IME and that it can insert text
* Switch to DEU. Check that `AltGr m` produces a `mu` symbol.
Check that grave (`\``) (a dead key) doesn't immediately output
anything, then press `e`; that produces an `e` with a grave
diacritic. Grave followed by space emits grave. Grave
followed by grave emits a grave and holds the second grave; pressing
`e` at this point now emits `e` with a grave diacritic.
(This is a difference from the "normal" system behavior, which
would just emit two graves in a row, then a regular `e`).
* Switch to ESP. Check that `AltGr 4` (tilde) doesn't immediately
output anything, then press `n`; that produces an `n` with the
tilde diacritic.
* Change `use_dead_keys = false`. Now verify in DEU that `grave`
just emits grave. In ESP, verify that `AltGr 4` just emits
a tilde.
* Switch back to ENG. Verify that `ALT-space` pops up the system
menu.
refs: #275
refs: #305
Change the cursor to an appropriate one of these when hoving
over and dragging a split.
Fix an issue where we wouldn't always change the cursor when
hovering over a split when multiple splits are present.
There's a few different knobs to turn, but this
commit turns them and we're now able to respect
opacity settings for both OpenGL/CGL and Metal
renderers.
closes: #141
This is similar in spirit to the work in 4d71a7913a
but for Windows.
This commit adds ANGLE binaries built from
07ea804e62
to the repo. The build and packaging will copy those into the same
directory as wezterm.exe so that they can be resolved at runtime.
By default, `prefer_egl = true`, which will cause the window
crate to first try to load an EGL implementation. If that fails,
or if `prefer_egl = false`, then the window crate will perform
the usual WGL initialization.
The practical effect of this change is that Direct3D11 is used for the
underlying render, which avoids problematic OpenGL drivers and means
that the process can survive graphics drivers being updated.
It may also increase the chances that the GPU will really be used
in an RDP session rather than the pessimised use of the software
renderer.
The one downside that I've noticed is that the resize behavior feels a
little janky in comparison to WGL (frames can render with mismatched
surface/window sizes which makes the window contents feel like they're
zooming/rippling slightly as the window is live resized). I think this
is specific to the ANGLE D3D implementation as EGL on other platforms
feels more solid.
I'm a little on the fence about making this the default; I think
it makes sense to prefer something that won't quit unexpectedly
while a software update is in progress, so that's a strong plus
in favor of EGL as the default, but I'm not sure how much the
resize wobble is going to set people off.
If you prefer WGL and are fine with the risk of a drive update
killing wezterm, then you can set this in your config:
```lua
return {
prefer_egl = false,
}
```
refs: https://github.com/wez/wezterm/issues/265
closes: https://github.com/wez/wezterm/issues/156
6c5a996423 was almost great...
the problem is that CTRL-W for example was generating a raw
uppercase W instead of a lowercase W which meant that CTRL-W
for split navigation in vim would trigger the close pane
key assignment.
I noticed that the built-in CTRL-SHIFT-1 assignment had
stopped working because that key press was being recognized
as CTRL-SHIFT-! with the recent changes in handling keyboard
input.
This commit sets the raw key to the position-based fallback
that we'd use if ToUnicode didn't return the correct mapping.
This is sufficient for this sort of un-modified key assignment
because the key is based on the virtual key code and is ignorant
of how the keyboard layout might compose those keys with SHIFT;
that is exactly what we want in this situation.
This commit adjusts the window layer to have it try to load EGL
implementations on macOS. This is important as the system
provided OpenGL implementation is deprecated and I wanted to
have a path forward for when it is finally removed.
If EGL fails to initialize, we fall back to the CGL/OpenGL
implementation that we used previously.
I've included binaries built for 64-bit intel from the MetalANGLE
project; here's how I built them:
```
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git --depth 1
git clone https://github.com/kakashidinho/metalangle --depth 1
cd metalangle
PATH=$PWD/../depot_tools:$PATH python scripts/bootstrap.py
PATH=$PWD/../depot_tools:$PATH gclient sync
PATH=$PWD/../depot_tools:$PATH gn --args="is_debug=false angle_enable_metal=true angle_enable_vulkan=false angle_enable_gl=false angle_build_all=false" gen out/Release
PATH=$PWD/../depot_tools:$PATH autoninja -C out/Release
```
Those steps are a little too long to want to put them directly
into the wezterm CI.
It is important for metalangle to be >= 8230df39a5
in order for scaling to be handled correctly when dragging windows
between monitors.
refs: https://github.com/kakashidinho/metalangle/issues/34
