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

374 Commits

Author SHA1 Message Date
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