In an earlier incarnation we needed to wake up more often to paint,
but we now should have reliable event sources for all of the
invalidation cases and we can thus sleep for much longer in
the main event loop.
refs: #770
When a window is being destroyed we expect the receiver end
to be disconnected, so we don't want to break out of the
message loop if a couple of residual windows fail to notify.
Removes the callbacks type and replaces event dispatch with
an async capable channel.
This makes it a bit simpler to model some of the window internals,
and to prepare for a wgpu enabled future.
This changes have been tested only on linux so far.
This should help us reason about whether a resize respected
our request.
This may break linux and windows builds, will fixup once
this is pushed.
refs: https://github.com/wez/wezterm/issues/695
We were getting abs() of the backing-rect-adjusted value, so we need to
restore the sign to avoid what should be logically cell position "-1"
being treated as cell position "1" and so on.
With this change, the logic in the gui layer successfully clamps the x
coordinate to zero when trying to drag left off the window.
NSCursor hide/unhide must be perfectly balanced otherwise
the cursor can vanish unexpectedly when the mouse leaves
the window, and not come back.
So, let's use NSCursor:setHiddenUntilMouseMoves instead; it's
not 100% fulfilling the promise of the API, but it's close enough
and should avoid the permanent invisibility issue.
refs: https://github.com/wez/wezterm/issues/618
This commit allows the x11 window implementation to detect changes
in the DPI that occur after a window is created.
These can occur when changing desktop resolution or when changing
the accessibility option for "Large Text" in gnome.
In order to avoid continually polling for the value on every resize,
we look for the `_GTK_EDGE_CONSTRAINTS` atom in our property change
notifications. This seems to be sent at least as often as the
dpi/scaling changes.
It's also worth noting that some dpi changes don't generate resize
events, so we can't just read the dpi value on every resize, because
we'd miss some of those changes.
Part of this commit changes the font scaling logic: previously
we'd keep a notion of "dpi scale" to apply. That dates from an
earlier time in wezterm where we didn't think that we knew an
actual dpi value.
The way that worked was that we'd compare our current guestimate
of the DPI against what we though the baseline OS dpi should be to
produce a scaling factor.
On X11 that dpi value is global and we'd effectively always produce
a revised scaling factor of 1 after we'd set up the initial window.
This commit changes that logic to just pass down the actual DPI value
to the font code. That DPI value already accounts for HiDPI scaling
so this is hopefully a NOP change for the other systems.
refs: https://github.com/wez/wezterm/issues/667
On macos, once all panes were closed, the GUI would request that the app
stop, but it wouldn't actually exit until a UI event occurred.
This was mostly noticeable when running debug builds from another
terminal.
Calling NSApp::abortModal is sufficient to knock us out of that state.
One of the default key assignments was registered as `SUPER+SHIFT+{`
which worked on macOS, but on Linux, would never match because the
keypress over there was (correctly) reporting as `SUPER+{`.
I originally thought that the user reported issue was a linux
normalization problem, but in looking deeper, the issue is really
that macos is doing something funky!
On macos we collect the interpreted key event as a string, and also
the interpretation of that event without any modifiers applied.
For letters this means that eg: `ALT-l` reports as `¬` for the
processed string and `l` for the unmodified string. That's good!
However, for punctuation we get a backwards result: SUPER+SHIFT+[
produces `[` for the processed text and `{` for the unmodified
text!
This commit tries to detect this, using a heuristic that is
potentially bad on non-US layouts: if both the processed and
unmodified strings are punctuation then we bias to the unmodified
version.
With that change, that key press is correctly reported as `SUPER+{`,
and we can fix the key assignment registration to reflect that.
I quickly checked the behavior of pressing that same physical key
combination with a DEU layout active, and it appears that the unmodified
stuff is also flipped there; we get a lower-case version of something
that I think should be uppercase. This commit doesn't change that
behavior:
```
key_event KeyEvent { key: Char('ü'), modifiers: NONE,
raw_key: Some(Char('Ü')),
raw_modifiers: SHIFT | SUPER,
raw_code: Some(33),
repeat_count: 1, key_is_down: true }
```
refs: https://github.com/wez/wezterm/issues/601
There's something fishy with colorspaces and blending.
This commit removes the `window::Color` type and replaces
it and the confusing array of color types exposed by the
`palette` crate with a pair of much simpler types:
`LinearRgb` - a tuple of f32 linear color components
`SrgbaPixel` - the u32 sRGBA pixel representation
This doesn't change anything about rendering, it just
makes it a bit simpler and makes the SrgbaPixel -> LinearRgb
conversion happen slightly earlier which shaves off some
ad-hoc conversions.
Refs: https://github.com/wez/wezterm/issues/544
* Make window invalidation more efficient by avoiding spawning a call
that spawns a call to invalidate the window. Just directly mark as
invalidated.
* Suppress default background erase
* hoist the bg_color calc for quads that don't have Cells outside of
its loop.
refs: https://github.com/wez/wezterm/issues/546
I'm not sure what exactly changed (perhaps it was a Windows updated?)
but window_background_opacity was only taking effect for windows
with no title bar.
I found that explicitly configuring a region makes transparency
work again.
refs: #553
Continuing along the same lines as the prior commit, the goal
of this commit is to remove the buffer transformation that was
part of uploading the texture to the GPU provided surface.
In order to do so:
* The sense of our local textures needs to change from bgra32 to rgba32.
bgra32 was a hangover from earlier versions of our window crate that
allowed direct-to-fb writes in software mode. We had to pick bgra32
for that for the broadest OS compatibility. I believe that that
constraint has been totally removed, although there is a chance that
this will flip the colors on macos.
* There was an additional linear-to-srgb conversion inlined in that
buffer transformation. I have no idea where that is needed because
the source data is carefully constructed as SRGB. I don't yet know
how to signal that, but for now I've moved that gamma correction
into the shader when we sample the texture.
With this change, timg playback now has vtparse as the hottest
region of code.
refs: #537
Two issues highlighted by profiling:
* Clearing the texture takes a non-trivial percentage of the profile.
The docs suggest that it is better to create a new texture than
to update large portions of a texture, so add some plumbing so
that we can do that in the first texture-full case.
* Next on the list is the code that translates from linear BGRA to
SRGBA. This is present for reasons that I believe are now legacy,
but for the moment: those two primitives now have faster and
easier implementations, so simplify to those.
This improves the timg video playback performance by ~10% for me.
refs: #537
The leftmost pixel was being set to at least 1 by the scale
function.
Fix that up by computing the x coordinate without calling
the scale function.
refs: https://github.com/wez/wezterm/issues/536
The previous behavior was to always treat ctrl-alt as altgr on Windows,
this has been done to better support altgr through a VNC session,
but this is very unintuitive when you don't need this behavior.
ref: #472
This is to support <https://github.com/wez/wezterm/issues/291>.
The window resized event happens asynchronously wrt. processing
a window resize, triggering at the end of the normal window
resize handling.
This commit introduces the notion of whether we are in full screen
mode or not in the underlying event callback, which is useful to
gate the desired feature, which is: when in full screen mode,
increase the padding for the window to center its content.
While poking around at this, I noticed that we weren't passing
the per-window config down to the code that computes the quad
locations for the window.
This commit also changes the font size increase/decrease behavior
so that in full screen mode it doesn't try to resize the window.
```lua
local wezterm = require 'wezterm';
wezterm.on("window-resized", function(window, pane)
local window_dims = window:get_dimensions();
local pane_dims = pane:get_dimensions();
local overrides = window:get_config_overrides() or {}
if not window_dims.is_full_screen then
if not overrides.window_padding then
-- not changing anything
return;
end
overrides.window_padding = nil;
else
-- Use only the middle 33%
local third = math.floor(window_dims.pixel_width / 3)
local new_padding = {
left = third,
right = third,
top = 0,
bottom = 0
};
if overrides.window_padding and new_padding.left == overrides.window_padding.left then
-- padding is same, avoid triggering further changes
return
end
overrides.window_padding = new_padding
end
window:set_config_overrides(overrides)
end);
return {
}
```
I've kept resizing in there because it doesn't appear to render
a border in mutter and seems useful.
I think I'll probably change WindowDecorations to bitflags so
that the user can control this, but first need to verify what
windows supports for this.
Connect the gui to the new shaping logic; this means that we
can now correctly render fg/bg color when the cursor moves
through the cells that comprise a ligature.
refs: https://github.com/wez/wezterm/issues/478
This function is intended to deal with certain kinds of ligatures
and certain combining sequences that don't have corresponding glyphs.
It isn't hooked up to the gui yet, but does have unit tests that
are probably mostly correct.
refs: https://github.com/wez/wezterm/issues/478
https://learnopengl.com/Advanced-Lighting/Gamma-Correction suggests
some good practices:
* Only enable SRGB output on the final draw call, so that all prior
stages can operate on linear values and avoid converting to/from
linear multiple times.
* The SRGBA textures automatically linearize when sampled, but:
* The RGB data must be SRGB (non-linear)
* The A channel is assumed to be linear!
This commit nudges us closer to that by:
* Converting the freetype coverage map from its linear value to
non-linear when rasterizing.
* Splitting the shader files into one per stage (background, lines,
glyphs) and only setting outputs_srgb for the glyph stage
refs: #491
A couple of times today while debugging things on wayland, I lost
keyboard input to wezterm.
I don't know if that is strictly a wezterm bug, or just a general
wayland bug (not long after, the whole mutter session hung, and
somehow wedged all processes with my uid).
So, this is a quick stab in that direction.
This fixes a longstanding issue under mutter where client side
decorations are in use. The decorations were being drawn too
early in the initialization of the window which could leave them
off-screen and weird. This was masked by a couple of mutter
related bugs with client side decorations.
With these changes I now get sane decorations under mutter,
and the toggle fullscreen action is now enabled as well!
closes: #224
However, I'm not able to create wayland windows any more on my nvidia
system (either with or without this change).
I don't know if this is specific to my nvidia drivers or something else
:-/
refs: https://github.com/wez/wezterm/issues/476
Dead key processing respects the
`send_composed_key_when_left_alt_is_pressed` and
`send_composed_key_when_right_alt_is_pressed` options.
See doc changes included in this commit for more info.
refs: https://github.com/wez/wezterm/issues/410
* Adds `CopyTo` and `PasteFrom` assignments that specify the
destination/source.
* Adds `default_clipboard_copy_destination` and `default_paste_source`
config options that specify the default destination/source for
existing `Copy` and `Paste` operations (for @bew)
* Deprecating `PastePrimarySelection` in favor of `PasteFrom`.
* Added `CTRL-Insert` -> `Copy` (for @Babar)
Aside from the new key assignment, these changes shouldn't change
the default behavior, but do make it easier to consider changing
that in a later commit.
They should allow for example:
* Set `default_clipboard_copy_destination = "PrimarySelection"` to
prevent populating the clipboard by default when using the mouse.
* Overriding the CTRL-Insert, CTRL-SHIFT-C to explicitly populate
the clipboard
* Set `default_paste_source = "PrimarySelection"` for middle click
to paste the selection.
* Overriding SHIFT-Insert, CTRL-SHIFT-V to explicitly paste from
the clipboard.
refs: #417
The heart of this issue was that the resize callbacks have two
layers of state; one in the low level window and one in the application
level window.
On Windows, the system triggers the low level callback prior to
opengl being initialized. Since the application level depends on
the opengl state, there are some code paths where it NOPs and
returns early if opengl isn't yet initialized.
When the system-wide display scaling is set to say 200%, the application
layer can't know the effective DPI of the window it is creating because
it doesn't know which monitor will be used or what its DPI will be.
New windows are created at the default DPI of 96, and we rely on the
resize events to detect the actual DPI and adjust the scaling in
the window.
The early call of the resize callback meant that the low level and
application level size/dpi state was out of sync and the result was
that the window had half as many pixels as it should, but that the
terminal model was still sized as though it had the correct amount
(twice as many as visible). This resulted in the window being too
small for the viewport.
The resolution is simple: we now suppress emitting the resize processing
until opengl has been initialized.
The test scenario for this is:
* Set system scaling to 100%
* Launch wezterm
* Set system scaling to 200%
* Observe that wezterm scales to match
* Press CTRL-SHIFT-N to spawn a new window
* Observe that the new window size matches the other window (previously
this one would be half the size)
While I was looking at this, I noticed that the manifest didn't
match the DPI awareness that we have in the code, so update that.
refs: https://github.com/wez/wezterm/issues/427
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
This changes the ALT/dead key behavior a little bit more,
and in a way that is likely more useful to terminal users.
The default behavior is that system dead key processing is enabled.
For example, with DEU keyboard layout activated:
* `^` `<SPACE>` results in a single `^`
* `^` `e` result in those two characters combining into an e with a
diacritic.
If the config sets `use_dead_keys = false` then the behavior changes;
wezterm probes the active keymap to determine which keys are marked
as dead keys and computes their single character expansion. When
the dead key is pressed then that expansion is substituted instead.
So `^` is simply `^`.
In order to pull this off, the window layer needs to selectively
call `TranslateMessage` for the system dead key expansion case
instead of unconditionally in the global message loop.
As a result of *that*, it means that we don't perform the default ALT
key translation for every key press any more. I looked to see how old
friend putty handles this and found that it only allows default system
processing for ALT-space and ALT-F4. I was resistent to selectively
processing system shortcuts because the full set are effectively
unknowable to an application and I didn't want to try to replicate
a wide selection of varying keypresses. I'm fine to only allow
these two, so this commit does that, and reverts the portion of
the prior commit that prevented passing general ALT key combinations
through.
refs: #275
refs: #296
For some definition of improve, at least.
On Windows, ALT is basically reserved by the Window management
layer for functions such as ALT-space, ALT-F4 and so on.
Windows doesn't provide a method by which an application can
test whether a given key would be processed by the default
window procedure so we're in a bit of a bind in terms of
allowing ALT+a keypress to do something meaningful in the
terminal.
What I've settled on for now is:
On Windows only, if ALT is pressed, allow matching key assignments that
include ALT to be matched. If there are no key assignments, then DON'T
pass the key press to the active pane, and instead allow it to be passed
to DefWindowProc. This allows ALT-space to be handled correctly,
provided the user hasn't defined an ALT-space key assignment of their
own.
This may have some unforeseen consequences. For example, ALT-<number>
is a readline binding that repeats an argument a number of times.
This change "breaks" that, but the user can provide a key assignment
to `SendString` the equivalent sequence to restore that behavior.
I'm kindof hoping that no one notices, but I'm prepared to explicitly
add default key assignments for that.
The other aspect of this commit is that I now understand a bit better
what a dead key is and how they should be handled. I've tested the
behavior of wezterm with these changes and the behavior is consistent
with a regular CMD window when I have the DEU keymap active.
Specifically, using the on-screen keyboard, if I click `^` then click
`e` wezterm will emit `ê`. If I click `^` then `^` then wezterm emits
`^^`.
refs: #275
refs: #296
This appears to be an unexpected consequence of 6708ea4b36
but thankfully that change allows de-coupling shift processing
from the ctrl processing in this block of code.
refs: #275
It's not clear why the first choice isn't always the right choice
for some users.
This commit changes the logic to try all potential configs,
one after the other, until we find one that sticks.
I don't know if this will work in practice: I suspect that
trying to configure one of them may prevent later configs from
being used.
But maybe it will, and it may reveal more information about
what the real cause of the problem is.
refs: #272
This is imperfect in that it may feel slightly off for very large
or very small font sizes, but it feels more similar to the scroll
speed in eg: iTerm2 with these changes.
refs: #206
To reproduce the problem, maximize wezterm, then press CMD-N.
This commit tells the window not to use cocoa native tabs and
instead really create a new window when we ask it to create
a new window.
closes: #254
025732d00f introduced deferred
window creation; the creation would get scheduled into the
spawn queue and then get run again a few milliseconds later
on the main thread.
For reasons that I don't understand, returning to the scheduler
loop to flush or otherwise process messages causes a wayland
protocol error.
Adjusting the notify routine to dispatch immediately if we're
already on the mux thread seems to resolve this.
While looking at this, I cleaned up a destruction order issue
with the opengl state that was then causing a segfault on shutdown.
I also removed a bit of dead paint related code that doesn't
appear to be needed any more.
refs: #293
This was broken by the changes in
aad493ab2a. The issue was that the
channel send didn't wakeup the receiver. I'm not sure why, and I tried
a couple of different async channel implementation.
Doing the simplistic solution here works reliably.
This is a bit of a switch-up, see this comment for more background:
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
This commit:
* Adds a pre-compiled mesa3d opengl32.dll replacement
* The mesa dll is deployed to `<appdir>/mesa/opengl32.dll` which by
default is ignored.
* When the frontend is set to `Software` then the `mesa` directory
is added to the dll search path, causing the llvmpipe renderer
to be enabled.
* The old software renderer implementation is available using the
`OldSoftware` frontend name
I'm not a huge fan of the subdirectory for the opengl32.dll, but
I couldn't get it to work under a different dll name; the code
thought that everything was initialized, but the window just rendered
a white rectangle.
If we've failed to initialize EGL, try setting `LIBGL_ALWAYS_SOFTWARE=true`
in the environment and make another pass at initialization in the hope
that it brings up something usable.
This commit only impacts linux systems at the time of writing.
I've made the line that logs the GL implementation information
have `error` level again, because it is more convenient for me
even if it isn't technically an error.
refs: https://github.com/wez/wezterm/issues/272
(but isn't the true fix; this is just trying to make the consequences
of that problem less. I would like to get that fixed correctly)
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
(which discusses what I think the end state should be)
This could be reproduced via `wezterm connect localhost`.
This bug was surfaced after the last release added a Drop impl
to cleanup the display.
This commit tracks the display in the connection.
closes: https://github.com/wez/wezterm/issues/252
This isn't a fix by any stretch of the imagination, but it stops
a crash. Should be good enough until I get a chance to fix this
properly.
refs: https://github.com/wez/wezterm/issues/252
This tidies up the valgrind output some more, but seems to highlight
some leaks in the egl implementation around init/shutdown.
I still don't see a smoking gun for a memory leak that grows over time.
refs: https://github.com/wez/wezterm/issues/238
When running on a 30bpp display with 2 bit alpha, eglChooseConfig
will match and list the 10bpc configuration first, which don't match
the desired pixel format.
Filter the config list so that it only includes 8bpc configurations.
refs: https://github.com/wez/wezterm/issues/240
In refs: https://github.com/wez/wezterm/issues/240 there are a number
of configurations that report 0 for the alpha size and where we are
unable to otherwise find a working config.
This is a speculative commit to releax the alpha channel size to
basically anything available and see if that helps.
This commit refactors the wayland EGL init code to call into the
non-wayland init code which is more in the spirit of DRY.
It also highlights that we were requesting PBUFFER and PIXMAP capable
contexts in the non-wayland case. Since we appear to survive without
those in the wayland renderer, presumably we can survive without them
in all cases.
This may help with activating opengl for this issue:
refs: https://github.com/wez/wezterm/issues/240
While looking into what it might take to support 10bpc (30bpp) displays
(https://github.com/wez/wezterm/issues/240) I was experimenting with
Xephyr at a reduced 16bpp depth and noticed that the server still
offered a 32bpp TrueColor depth option.
This commit adjusts the window/bitmap code to allow it to select depths
24bpp or 32bpp, preferring the largest depth. we restrict ourselves to
24 and 32 bit selections for this, as those appear to be bit for bit
compatible for the r/g/b channels. I suspect that 10bpc will require
some scaling somewhere.
This change allows running wezterm against the reduced depth Xephyr, but
since Xephyr doesn't support GL it runs with the software renderer; I
don't know quite how opengl is going to play with this. I can confirm
that running wezterm on my native 24bpp display when it picks a 32bpp
visual does run with opengl enabled, so maybe this is good enough?
