This is a working tentative at fixing text expansion/injection done by
Espanso by default, where XKB doesn't seem to detect the pressed
modifiers `Ctrl+Shift` before pressing `v`.
refs: #3840
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
