Weirdly, the rust compiler is suddenly complaining about this,
when this file hasn't changed.
```
error[E0283]: type annotations needed
--> window\src\os\windows\window.rs:2398:26
|
2398 | if vk <= u8::MAX.into() {
| -- ^^^^
| |
| type must be known at this point
|
= note: cannot satisfy `u32: PartialOrd<_>`
help: try using a fully qualified path to specify the expected types
|
2398 | if vk <= <u8 as Into<T>>::into(u8::MAX) {
| ++++++++++++++++++++++ ~
error[E0283]: type annotations needed
--> window\src\os\windows\window.rs:2415:32
|
2415 | if leader.1 <= u8::MAX.into() && key.1 <= u8::MAX.into() {
| -- ^^^^
| |
| type must be known at this point
|
= note: cannot satisfy `u32: PartialOrd<_>`
help: try using a fully qualified path to specify the expected types
|
2415 | if leader.1 <= <u8 as Into<T>>::into(u8::MAX) && key.1 <= u8::MAX.into() {
| ++++++++++++++++++++++ ~
```
Note that this also does not respect dpi_by_screen; this is for
consistency in behavior and reported values.
Once we can produce the correct overridden value in
dispatch_pending_event, we can update these functions to return
the same data.
refs: #4096
This is a baby step towards handling dpi_by_screen.
I don't want to do the actualy per-screen stuff here;
it touches stuff around the edges of SCTK and there is a pending,
significant, rewrite of that code needed to upgrade to a more
recent version of SCTK + wayland-protocols, and I don't want to waste
my effort on the intermediate state.
https://github.com/wez/wezterm/issues/3996#issuecomment-1636830740
refs: #4096
Maintain a cache of the positions of the various named screens,
and use that to resolve the screen of the current window, and
from there we can resolve the correct dpi_by_screen screen.
Make dpi and dpi_by_screen config changes generate a resize
event with the updated dpi.
refs: #4096
Allows specifying the precise dpi to use on a per-screen basis:
```lua
return {
dpi_by_screen = {
["Built-in Retina Display"] = 144,
},
}
```
The screen names are the same as those returned from
`wezterm.gui.screens()`.
Changing either `dpi` or `dpi_by_screen` in the config will now cause
the window to be immediately resized/adjusted to the changed dpi
override.
Ultimately, I'd like to deprecate `dpi` in favor of `dpi_by_screen`,
but can't do that until this functionality is ported to windows, x11
and wayland.
refs: #4096
This is fixing a regression introduced by the fix for #2845.
The resolution for this is relatively straightforward, but took a bit
of effort to plumb.
Previously:
* CTRL/ALT/SUPER-modified keys with no explicit expansion would end
up just taking the US layout version of the key. That worked well
for the intended problem with non-latin layouts, but for eg: German
layouts it caused expansion to totally the wrong thing
Now:
* CTRL/ALT/SUPER-modified keys which effectively expand to non-ascii
text (eg: cyrillic "Es") now take the equivalent key press from the
US layout (which would be "c" in the "Es" case). For European
layouts this heuristic seems to avoid unexpected effects, but could
do with some validation from native users.
To support this, the xkb code splits the `Keyboard` struct out from
some of the higher level logic and introduces a `KeyboardWithFallback`
struct that is built out of the user-selected keyboard layout, and
the fallback keyboard. Now the fallback keyboard is fed the same
key inputs as the selected keyboard to correctly model the key
combinations.
refs: #3610
refs: #3933
On Wayland, copy mode often doesn't actually update the clipboard.
Specifically, it only works one time after a pointer enter or pointer
button event, then doesn't work again until the next event.
This is because the Wayland protocol serial number in
CopyAndPaste::last_serial is only updated by pointer enter and pointer
button events. So, subsequent copies using only the keyboard reuse the
same serial number and get ignored. last_serial used to be updated for
keyboard events, too, but that was (accidentally?) dropped in commit
0a00ffe98b.
Commit 0a00ffe98b also added another
last_serial to WaylandConnection which is updated for keyboard events
but isn't used anywhere as far as I can tell.
So, to fix this bug, let's get rid of CopyAndPaste::last_serial and
replace it with WaylandConnection::last_serial, which is now updated for
pointer and keyboard events.
closes: #3843
Error message I've been seeing the past couple of days:
Unable to resolve appearance using xdg-desktop-portal: invalid value:
string "()", expected at least one field signature between `(` and `)`:
invalid value: string "()", expected at least one field signature
between `(` and `)`
When trying to display a 4k image there is a high chance that
we'll run out of texture space and then render with no images
displayed.
This commit changes the binary yes/no allow-images into a a series
of attempts: display at natural size, scale down by 2, 4, then 8,
then give up on images.
While looking at this, I noticed that we had a TOCTOU in the blob lease
stuff in the case where we might very quickly try the handle the same
image in succession, and end up deleting a file out from under a live
lease.
I've put in place a simple bandaid for that, but it's probably worth
revisiting the concurrency model for that.
Don't fallback to some other serial.
In a new version of SCTK, it looks like the serial we pass should
be the serial from the time we entered the surface, rather than
the latest serial that we have.
In practice, this commit uses None for the serial which seems to
have better results, but may come back to haunt us until we upgrade
to the latest SCTK.
refs: https://github.com/wez/wezterm/issues/3334#issuecomment-1515141539
This allows for potentially listing multiple candidate cursor names,
like we do for x11, but doesn't add any.
Attempt to load default if our desired cursor is not found.
refs: https://github.com/wez/wezterm/issues/3334
For eg: RU layout, CTRL-S shouldn't result in ы in the context
of a terminal.
The approach taken here is similar to kitty; when the key combination
doesn't produce a definitive composed output, and when any of
ctrl/alt/super are present, we treat the keypress as though it were
the same as the one from the system default keymap.
The result is that ctrl-c now works like ctrl-c and alt-b and alt-f work
like their latin counterparts.
Hopefully there are no downsides to this!
refs: https://github.com/wez/wezterm/issues/2845
refs: https://github.com/kovidgoyal/kitty/issues/606
The main part of the problem is that NSWindow::isZoomed lies to us
sometimes.
This is a relatively gross workaround.
Add missing invalidation after setting the content size; that prevents
janky when dragging the window between monitors.
Removed some redundant Dimensions computation from that method; nothing
ever read it.
refs: https://github.com/wez/wezterm/issues/3503
This pulls in almost all of the original PR in #2235.
I skipped a dead key case that I recall being tricky:
I didn't want to break the non win32-input mode version
of that.
I'd be happy to have that case re-evaluated in a smaller
PR where we can focus on its details.
Co-authored-by: Dominik Kreutzer <kreudom@gmail.com>
macos doesn't have a num lock concept, so there is no num lock state
reported in modifiers. wezterm doesn't emulate that state because it
cannot guarantee to observe all key presses and correctly track it.
We were missing encoding of these for the base xterm encoding
(I haven't daily driven a keyboard with a numpad in over 10 years!).
Improve mapping for the kitty protocol.
refs: https://github.com/wez/wezterm/issues/3478
This commit teaches the termwiz layer about positional modifiers,
and expands our modifier concept to also pass through led states
such as caps lock and num lock.
Those aren't actually keyboard modifiers, but the state is useful
to recognize.
Adjust the shift key normalization so that we don't uppercase
alpha characters when both SHIFT and CAPS_LOCK are held.
This processing will remove both SHIFT and CAPS_LOCK in that
situation.
Add a method to KeyEvent that will undo the OS keyboard layer
normalization of positional to generic modifier key presses.
eg: the OS may map LeftControl -> Control, but we actually
prefer to have LeftControl so if we can unambiguously reverse
that mapping, we do so.
refs: #3476
refs: #3475
