Adds some detection to see if the active keyboard layout has
AltGr, and if so, adjust our key mapping logic to accomodate it.
With this change, when using an ENG layout, I can use either left
or right alt-b/alt-f to move through words in wsl. When I switch
to DEU my left alt is still alt and my right alt causes the
Windows On-Screen keyboard to act as though AltGr is pressed.
I can then use the On-Screen keyboard to press the `<` key which
is to the left of the `Z` key on a German layout and have it produce
the `|` character.
refs: https://github.com/wez/wezterm/issues/185
We switched to using clipboard because of problems under XWayland.
These days we have much better native Wayland support and folks
should use that.
Test plan:
In one window:
```
echo "clipboard" | xclip -i -selection clipboard; echo "primary" | xclip -i -selection primary;
```
then start `wezterm` and press shfit-insert.
Prior to this change we'd always print `clipboard`.
After this change we'll print `primary`.
However, if you run:
```
WEZTERM_X11_PREFER_CLIPBOARD_OVER_PRIMARY=1 wezterm
```
then we'll use the old `clipboard` behavior.
Teach the window layer about window icons and implement the
plumbing for this on X11.
For Wayland there is no direct way to specify the icon; instead
the application ID is used to locate an appropriate .desktop filename.
We set the app id from the classname but that didn't match the installed
name for our desktop file which is namespaced under my domain, so change
the window class to match that and enable the window icon on Wayland.
refs: https://github.com/wez/wezterm/issues/172#issuecomment-619938047
@kalgynirae showed me weirdly laggy behavior when moving the mouse
in front of his x11 window. My suspicion was that this is somehow
related to updating the mouse cursor glyph, and looking at this code
there were two things that might influence this:
* We weren't saving the newly applied cursor value, so we'd create
a new cursor every time the mouse moved (doh!)
* We'd create a new cursor id each time it changed, and then destroy it
(which isn't that bad, but if it contributes to lag, maybe it is?)
This commit addresses both of these by making a little cache map
from cursor type to cursor id.
I can't observe a difference on my system, so I wonder if this might
also be partially related to graphics drivers and hardware/software
cursors?
Hiding a window is implemented as miniaturizing the window, which
is typically shown with an animation of the window moving into the
dock.
This is not the same as the application-wide hide function in macOS;
that function hides the entire app with no animation. We don't use
that here because our Hide function is defined as a window operation
and not an application operation.
refs: https://github.com/wez/wezterm/issues/150
The opengl based render first clears the window to the background
color and then renders the cells over the top.
on macOS I noticed a weird lighter strip to the bottom and right of
the window and ran it down to the initial clear: our colors are SRGB
rather than plain RGB and the discrepancy from rendering SRGB as RGB
results in the color being made a brighter shade. This was less
noticeable for black backgrounds.
Remove a normalizing function that made assumptions based on the
keycaps that did not hold up when selecting Dvorak as an input
source. For example "CTRL-C" where `C` is the key with the C keycap
would send `CTRL-C` even when Dvorak was selected; it should send CTRL-J
in that layout.
I think with the other normalization that happens in the termwindow
layer we don't need this function any more.
The default values are 3 lines. With this change, scrolling speed now seems
similar to other programs like cmd.exe. Before this change it feels too slow.
I noticed my trackpoint or touchpad reports a lot of < 120 (WHEEL_DELTA) events.
They shouldn't be ignored.
Also https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel says:
> The wheel rotation will be a multiple of WHEEL_DELTA, which is set at 120.
> This is the threshold for action to be taken, and one such action (for
> example, scrolling one increment) should occur for each delta.
>
> The delta was set to 120 to allow Microsoft or other vendors to build
> finer-resolution wheels (a freely-rotating wheel with no notches) to send
> more messages per rotation, but with a smaller value in each message. To use
> this feature, you can either add the incoming delta values until WHEEL_DELTA
> is reached (so for a delta-rotation you get the same response), or scroll
> partial lines in response to the more frequent messages. You can also choose
> your scroll granularity and accumulate deltas until it is reached.
macos generates fractional distance values for the mouse wheel,
with one tick starting at 0.1. We were truncating this to a 0 row
move, which meant that you'd need to build up some acceleration to
move the rows when all you really wanted was a single tick.
This commit changes things so that we round up to at least 1.0 in this
situation.
The IME stuff on macos tends to swallow repeats for some keys.
Ugh. So this commit adds an option to disable the use of the IME.
Switching away from it effectively inverts the meanging of backspace
and delete (because our method is no longer called by the IME), so
we need to check for that and remap it. Ugh.
Ugh.
double clicks weren't registering correctly with the new selection
logic. Tell windows that we're doing all our own click counting
and simplify the logic.
Force using xcb-util 0.2.1 precisely because 0.2.2 pulls in a
conflicting major version of xcb (0.8 -> 0.9).
It's a non-trivial upgrade: the types around xkb are different
and features need to be specified in the manifest to enable compilation
of the things that we depend upon.
In addition, xkbdcommon, on which we depend, requires xcb 0.8 and
results in pulling in two conflicting versions of the crates.
It's a bit of a painful situation and will require some effort to
figure out how to upgrade the xcb dependency, when we're ready for that.
refs: https://github.com/meh/rust-xcb-util/issues/12
On x11 we'd get just a single line per scroll wheel tick.
Contrast with Wayland where we get multiple.
This config change makes us feel more snappy by default on X11.
I'd like to make this configurable using the live configuration
infra, but we don't currently have a way for this crate to see
that config, so this just changes the default to be "better".
refs: https://github.com/wez/wezterm/issues/92
This reverts commit bfa8d0c207,
which proved not to be needed because it was already covered
by the `KeyboardEvent::Enter` and `KeyboardEvent::Leave` handling.
On a Fedora 31 system running Wayland I noticed that wezterm and
the compositor were running pretty hot on their respective CPU
cores.
It turned out that we had a lot of
[Refresh](https://docs.rs/smithay-client-toolkit/0.6.4/smithay_client_toolkit/window/enum.Event.html#variant.Refresh)
events being generated and consumed. We were treating this as needing
a full paint so we'd be effectively continually running the opengl
paint cycle over and over.
The docs for that event say that it is intended to refresh the client
decorations so let's focus it towards that instead. This does bring
the CPU usage back down to intended levels.
I believe this hot CPU usage to be compositor-dependent: this is the
first I've seen of it out of 4 different Wayland environments!
