1
1
mirror of https://github.com/wez/wezterm.git synced 2024-12-25 14:22:37 +03:00
Commit Graph

439 Commits

Author SHA1 Message Date
Wez Furlong
4e2b2eddba split shaders, adjust srgb opengl render settings
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
2021-02-20 17:12:36 -08:00
Wez Furlong
41cb9d3f38 wayland: attempt to handle seat changes that impact the keyboard
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.
2021-02-13 21:07:22 -08:00
Wez Furlong
b4ded64e14 wayland: fix an issue with key repeat potentially hanging/spinning 2021-02-13 19:47:06 -08:00
Wez Furlong
f697de82fc wayland: fix initial window decoration, toggle full screen
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
2021-02-13 11:02:04 -08:00
Wez Furlong
894d056947 wayland: allow matching raw modifiers for raw:123 key bindings 2021-02-13 09:11:55 -08:00
Greg V
58e2a181f2 wayland: do not create OpenGL context before the configure event
The existing code seems to use "configure" for just resizes,
so introduce a "start" flag in pending events to handle the
initial configure.
2021-02-12 16:56:24 -08:00
Wez Furlong
a14e3669f2 window: update smithay-client-toolkit
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
2021-02-12 08:19:51 -08:00
Wez Furlong
d9275e110c deps: update metrics from 0.12 -> 0.14 2021-02-03 23:50:29 -08:00
Wez Furlong
0c6f0cac1b x11: track primary selection and clipboard requests separately
otherwise we get confused about the state of these and paste
the wrong thing
2021-02-01 07:50:48 -08:00
Wez Furlong
f541e923de macos: also respect use_dead_keys = false
refs: #410
2021-01-31 17:32:11 -08:00
Wez Furlong
6bfadfac0a macos: handle dead keys without IME
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
2021-01-31 17:06:30 -08:00
Wez Furlong
b201e43b94 window: doc comment for opacity config
refs: #445
2021-01-30 08:08:11 -08:00
Wez Furlong
baf168e458 window: slightly condense opaque/shadow setting logic
refs: #445
2021-01-30 08:02:48 -08:00
Zeyi (Rice) Fan
6b9401365c
Only disable drop shadow on macOS when window background opacity is transparent (#445)
* only set shadow when background is transparent

* set opaque correctly
2021-01-30 07:58:53 -08:00
Wez Furlong
8dad34fa61 more configuration options for Copy/Paste
* 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
2021-01-27 10:20:17 -08:00
Wez Furlong
aee37784e5 Windows: fix initial window size when display scaling != 100%
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
2021-01-18 09:27:04 -08:00
Wez Furlong
0ef89f3de0 window: remove some dead code on Windows
Since removing non-GL usage, this code is dead.
2021-01-17 10:29:49 -08:00
Wez Furlong
697d41aeb1 Render the various underline styles
```
$ printf "\x1b[58;2;255;0;0m\x1b[4msingle\x1b[21mdouble\x1b[60mcurly\x1b[61mdotted\x1b[62mdashed\x1b[0m"
```

refs: https://github.com/wez/wezterm/issues/415
2021-01-05 23:46:15 -08:00
Wez Furlong
b5e5f2a764 window: fix painting on x11
Need to clear paint_all otherwise we don't settle and flush buffers.
2020-12-30 09:42:16 -08:00
Wez Furlong
cc4cdd81b3 window: remove avx code in bitmaps/mod.rs
I don't think it is worth the complexity of keeping this around;
we rarely do direct bitmap stuff any more.
2020-12-29 14:26:57 -08:00
Wez Furlong
c73e1d3924 window: remove PaintContext 2020-12-29 13:53:20 -08:00
Wez Furlong
38a0137660 window: remove now-dead code on Windows 2020-12-29 13:42:18 -08:00
Wez Furlong
1ca2aeaeb4 window: remove now-dead code for x11/wayland 2020-12-29 13:40:50 -08:00
Wez Furlong
1af1c85818 window: fixup build for x11/wayland 2020-12-29 13:35:59 -08:00
Wez Furlong
4f80fd9bcd window: macos: remove dead code 2020-12-29 13:29:59 -08:00
Wez Furlong
cf6914c5d8 window: remove non-opengl paint, rename paint_opengl -> paint 2020-12-29 13:25:35 -08:00
Wez Furlong
972c07a692 window: update examples for opengl-only-ness 2020-12-29 13:15:16 -08:00
Wez Furlong
5a3c6a6b15 window: macos: remove non-opengl back buffer 2020-12-29 12:52:44 -08:00
Wez Furlong
709682079e window: macos: refactor now opengl is always enabled
Hoist opengl out of a submodule.
2020-12-29 12:47:25 -08:00
Wez Furlong
cf418c34e3 window: consolidate opengl_initialize with created callback
Since we now always init opengl and fail to create a window if that
fails, may as well combine these two callbacks.
2020-12-29 12:44:39 -08:00
Wez Furlong
ec7d511750 window: implicitly enable_opengl at new_window creation 2020-12-29 12:31:25 -08:00
Wez Furlong
4c22de9f6d window: make opengl always required 2020-12-29 12:13:23 -08:00
Wez Furlong
7cf68365a5 deps: misc updates 2020-12-29 09:24:34 -08:00
Wez Furlong
c68bf92bcd window: implement FullScreen for x11
refs: https://github.com/wez/wezterm/issues/177
2020-12-28 10:59:53 -08:00
Wez Furlong
f8f8dc7240 remove now-dead code 2020-12-27 22:37:52 -08:00
Wez Furlong
d302f82335 window+gui: macOS: add native_macos_fullscreen_mode option
Defaults to false.  If set to true, the ToggleFullScreen action
prefers native macOS fullscreen mode.

refs: https://github.com/wez/wezterm/issues/177
2020-12-27 22:34:31 -08:00
Wez Furlong
cd997cbe48 window+gui: migrate prefer_egl to WindowConfiguration 2020-12-27 22:06:04 -08:00
Wez Furlong
228356105e window+gui: migrate enable_wayland to WindowConfiguration 2020-12-27 22:00:51 -08:00
Wez Furlong
fb53f98295 window+gui: migrate windows dead keys config to WindowConfiguration
untested as I'm on a mac, but seems like it might compile...
2020-12-27 21:56:16 -08:00
Wez Furlong
44ca61da66 window+gui: introduce WindowConfiguration trait
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.
2020-12-27 21:51:56 -08:00
Wez Furlong
7ae52cd2b5 wezterm: plumbing for FullScreen action
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
2020-12-27 19:15:47 -08:00
Wez Furlong
cbf29c2e53 window: x11: remove SHIFT state from KeyCode::Char(_)
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
2020-12-25 10:29:30 -08:00
Wez Furlong
79c945a893 Probably improve compatibility for AltGr inside VNC on Windows
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
2020-12-24 16:23:12 -08:00
Wez Furlong
39d6549f23 adjust some log levels on windows around EGL init 2020-12-22 11:40:03 -08:00
Wez Furlong
80214319ae adjust log levels
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
2020-12-20 22:01:06 -08:00
Wez Furlong
c1fa08319e deps: upgrade euclid -> 0.22 2020-12-10 10:03:30 -08:00
Wez Furlong
c72af9547a window: record raw key code in KeyEvent on Windows 2020-12-09 22:19:54 -08:00
Wez Furlong
c6334a45dd extract window::input to wezterm-input-types 2020-12-09 13:48:23 -08:00
Wez Furlong
92827a1bea wezterm: default dpi on macOS is now 72
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
2020-12-06 18:34:06 -08:00
Wez Furlong
b2be2963a1 wezterm: fixup input processing for Option/dead keys
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
2020-12-06 17:49:26 -08:00
Wez Furlong
61c52af491 wezterm: add raw_code concept to input layer
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
2020-12-06 13:41:29 -08:00
Wez Furlong
4e7f3cc75a window: add optional KeyCode::raw_code field
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.
2020-12-06 13:41:29 -08:00
Wez Furlong
d6a9ed5ae7 window: x11: remove a little redundant code from key processing 2020-12-06 13:41:29 -08:00
Wez Furlong
9bebc811d0 window: fix build when opengl is not enabled 2020-11-22 09:24:07 -08:00
Wez Furlong
fba2159839 deps: remove unused deps
Not all of these are needed in these crates (copypasta resulting
from splitting out modules)
2020-11-20 12:37:38 -08:00
Wez Furlong
fd3c062daf cargo fmt
latest rust changed the formatting options, so reformat to
avoid the CI being unhappy.
2020-11-20 09:06:21 -08:00
Wez Furlong
18e010f1df deps: normalize the lazy-static version 2020-11-13 08:15:35 -08:00
Jeremy Fitzhardinge
e95c7ad855 Fix compiler warning by moving x86-64 specific variable into the guard 2020-11-11 20:31:18 -08:00
Wez Furlong
5b8b41adbb window: macos: fix mouse cursor for dragging splits 2020-11-06 15:02:38 -08:00
Wez Furlong
403d002d0a window: fix potential crash with multiple egl windows on windows
I didn't actually see this crash, but the same potential problem
was present, so adjust the code as per 9712d4d03c

refs: #316
2020-11-01 10:28:17 -08:00
Wez Furlong
9712d4d03c window: fix crash with multiple egl windows on macos
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
2020-11-01 10:18:40 -08:00
Wez Furlong
92bdc4a3b0 Revert "window: alternative shadow/ghost/macos fix"
This reverts commit f2b504ee1f9a607fe8965e96b659bca282147672;
we prefer the overall snappier perf from not having a shadow.

refs: #310
2020-10-28 17:55:15 -07:00
Wez Furlong
f2b504ee1f window: alternative shadow/ghost/macos fix
This one invalidates the shadow when we invalidate the window,
so we should get to keep the shadow and lose the ghosts.

refs: #310
2020-10-28 16:08:33 -07:00
Wez Furlong
e3100c937f window: maybe fix ghostly artifacts on macos
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
2020-10-28 14:08:04 -07:00
Wez Furlong
284a4ebfbb window: fix mouse wheel reporting on Windows
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.
2020-10-24 21:41:11 -07:00
Wez Furlong
52908712c6 wezterm: add excess padding for image protocols
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
2020-10-24 12:46:49 -07:00
Wez Furlong
f4066747d2 wezterm: improve texture atlas allocation
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
2020-10-23 13:57:58 -07:00
Wez Furlong
627d21cbac cargo fmt 2020-10-23 09:07:11 -07:00
Wez Furlong
e2311aaa73 window: more fun with dead keys on Windows
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
2020-10-23 08:47:11 -07:00
Wez Furlong
f12df0be9b window: add cursors for resizing up/down left/right
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.
2020-10-22 09:23:05 -07:00
Wez Furlong
aa660d5d06 wezterm: apply transparency tint to all background colors
refs: https://github.com/wez/wezterm/issues/141#issuecomment-711442986
2020-10-18 21:51:12 -07:00
Wez Furlong
191b047126 macos: implement opacity for CGL and Metal
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
2020-10-18 14:00:06 -07:00
Wez Furlong
2364b0a20e Windows: enable window_background_opacity
This causes DWM to respect the alpha channel we set during rendering,
allowing the window opacity to be respected on Windows.

refs: #141
2020-10-18 11:13:34 -07:00
Wez Furlong
cac02b3bbb Windows: fix enabling dark mode
This got broken by a recentish windows update.
2020-10-17 19:48:43 -07:00
Wez Furlong
b7e303f39c Windows: prefer to use Direct3D11 via ANGLE
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
2020-10-17 19:08:16 -07:00
Wez Furlong
f6afec27f5 windows: lowercase the raw key
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.
2020-10-17 14:02:06 -07:00
Wez Furlong
6c5a996423 windows: set KeyEvent::raw_key in key processing
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.
2020-10-17 10:25:55 -07:00
Wez Furlong
4d71a7913a macOS: bundle and use MetalANGLE to enable Metal rendering
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
2020-10-17 09:34:01 -07:00
Wez Furlong
13cd24d9b5 Windows: improve ALT + dead key handling, part 2
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
2020-10-15 17:06:09 -07:00
Wez Furlong
5088c62954 Windows: improve ALT and dead key handling
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
2020-10-14 20:02:23 -07:00
Wez Furlong
5f0c859caa windows: fix an issue processing ctrl+shift for non-alpha keys
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
2020-10-14 18:12:03 -07:00
Wez Furlong
9e46ac83be Windows: force Mesa/Software mode when started in an RDP session
refs: #265
2020-10-14 09:21:30 -07:00
Wez Furlong
05b02e178b window: fix Hide action on Windows
This was hiding the window completely with no way to show it again(!).
Change it instead to minimize, which was the intent.

refs: #296
2020-10-14 08:42:55 -07:00
Wez Furlong
8fcad1c1ee egl: improve trace logging of successful choice
refs: #272
2020-10-13 19:45:43 -07:00
Wez Furlong
baebc81432 egl: try all configs one by one in case first choice fails
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
2020-10-13 19:22:37 -07:00
Wez Furlong
0a39328e9d macos: adjust trackpad scroll sensitivity
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
2020-10-12 19:24:23 -07:00
Wez Furlong
ce44ec2e70 macos: improve positioning for new windows
We used to always create them in the center of the screen,
but now subsequently created windows are offset slightly.
2020-10-12 17:54:44 -07:00
Wez Furlong
c8d59dffb6 macos: fix an issue where new windows created cocoa tabs
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
2020-10-12 17:20:12 -07:00
Wez Furlong
da2bba866d window: macos: trigger resize event when screen resolution changes
The easiest repro for this is dragging a window between monitors.

refs: #161
2020-10-12 11:29:17 -07:00
Wez Furlong
5257e34e2c window: update to latest glium version 2020-10-11 17:07:47 -07:00
Wez Furlong
dedfc4513b wayland: clear modifiers when keyboard focus changes
refs: #222
2020-10-11 10:02:37 -07:00
Wez Furlong
807ed3ba1e wayland: fixup timing issue on startup
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
2020-10-10 16:09:04 -07:00
Wez Furlong
5fb1414b69 fix clipboard on x11
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.
2020-10-09 11:07:18 -07:00
Wez Furlong
f497391958 gah, cargo fmt 2020-10-05 11:57:27 -07:00
Wez Furlong
bf266a326d maybe fixup build for windows 2020-10-05 11:57:08 -07:00
Wez Furlong
5eb4d32004 upgrade misc deps, notably, async-task 2020-10-05 00:06:01 -07:00
Wez Furlong
f3bccc7d08 window: X/Wayland: Software frontend is now llvmpipe
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
2020-10-01 20:03:45 -07:00
Wez Furlong
e6a858664f windows: Software frontend is now mesa llvmpipe
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.
2020-10-01 18:31:57 -07:00
Wez Furlong
6069eabc9b window: speculatively try enabling mesa llvmpipe as egl fallback
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)
2020-09-30 22:41:02 -07:00
Wez Furlong
6708ea4b36 window: normalize SHIFT modifier state
When a keypress is ASCII uppercase and SHIFT is held, remove SHIFT
from the set of active modifiers.

refs: https://github.com/wez/wezterm/issues/157#issuecomment-699516096
2020-09-26 09:17:51 -07:00