The workarounds added in #2498 and #2437 fixed stuck key/modifier bug
caused by wlroots commit e218990. But now that the commit was reverted in
0.19, the workarounds are no longer needed.
Removing the workarounds also fixes a minor regression with Fcitx5+Firefox
that pressing Ctrl+Enter in an input box causes stuck modifier.
Having a hover effect visible without interaction looks out of
place when there is no cursor (the cursor becomes hidden for/after
touch interaction until next mouse or tablet interaction). Just
clear the hover effect after touch-up to prevent this.
Note that SSD hover effects are still shown during touch-move and
touch-down.
Only use the touch protocol when no labwc menu is open.
This ensure that labwc menus will be closed on first touch
down/up since cursor emulation takes care of closing a
menu.
This prevents that a labwc menu stay open during touch
interactions in native touch mode.
It doesn't matter much since those are about the combination
of tablet and tablet tool. That said, this feels slightly more
natural.
As a consequence we always create a tablet tool and decide
indirectly via `tablet_get_coords()` and the returning surface
if mouse emulation should be used or not. Now we can also
add a `motion_mode` to the tablet tool which is slightly cleaner.
Omit cursor notifications from a pointer when a tablet
tool (stylus/pen) is in proximity. This is equivalent
to `handle_request_set_cursor()` and prevents a resize
cursor for out-of-surface scrolling with a tablet tool in
recent GTK4 (which uses the cursor shape protocol).
Using mouse emulation for a tablet tool mouse is just a practical
decision to let such a tool work more smootly, e.g. it avoids weird
menu issues in GTK applications. Since such a tool doesn't have
pen specifix axis like pressure or distance, no functionality is lost.
A solution fully in line with the protocol, which would pass the tool
mouse buttons to the client, would leave us with e.g. non-working
buttons in current GTK4 since they don't handle the buttons
reported from the tool mouse.
May be this changes in future. But for now, let's just be practical.
Before this patch, when followMouse and followMouseRequiresMovement are
both yes, we set the keyboard focus when the cursor moves within an
unfocused surface. However, kwin, xfwm4 and openbox all set keyboard focus
only when the cursor enters a surface.
This ensures all event listeners are removed before the emitting
wlroots object is being destroyed. This will be enforced with asserts
in wlroots 0.19 but there is no reason to not do it right now either.
This change in wlroots 0.19 is implemented via commit
8f56f7ca43257cc05c7c4eb57a0f541e05cf9a79
"Assert (almost all) signals have no attached listeners on destroy"
This commit moves the check against server->input_mode from the callers
of desktop_focus_view() into desktop_focus_view() itself. This
eliminates code duplications and makes it harder to mess up the window
stacking order while window switching.
I also added the same check in view_minimize() so that minimize requests
from panels never messes up the window stacking order (I think only this
should be described in the release note).
This commit restores the check removed in 7a6ecca.
Without the check, if followMouse="yes" and
followMouseRequiresMovement="no", osd_update() => cursor_update_focus() =>
desktop_focus_view() unexpectedly un-minimizes the window on cursor even
when the window is just a preview of window switcher. This caused some
strange behavior that a minimized window selected with window switcher is
immediately hidden after finishing window switching.
The protocol states that the wl_pointer motion coordinates must be
relative to the focused surface (e.g. the surface that last received
a wl_pointer enter event).
Before this patch, the coordinates were relative to the toplevel
surface instead, resulting in subsurface events having the wrong
coordinates when pressing a button over a subsurface and moving
the cursor outside of that subsurface.
Fixes: #2542
Prior to this commit, when we receive fine-grained scroll events from
touchpads that are bound to any mousebind, we leaked the scroll events to
the client unless the accumulated scroll delta exceeds the fixed threshold.
This was annoying for example when a user wants to ZoomIn/Out with
W-Up/Down mousebinds with a touchpad.
So this commit fixes it by not leaking the scroll events nor executing
actions when the accumulated delta doesn't exceed the threshold.
And make mousebind handlers use that one.
Also remove keyboard_any_modifiers_pressed() and replace its usage
with the new function.
Without this patch we would only request the modifier state of the
keyboard group which makes mousebinds involving keyboard modifiers
break for virtual keyboards like when using wayvnc. Same story for
hiding the workspace overlay or snapping to regions.
Fixes: #2511
683f67b7 introduced another regression that the modifier state (Ctrl) is
stuck when Ctrl+F is pressed in some applications like Firefox while
Fcitx5 is running. This caused mouse scrolls to zoom in/out the UI.
Let me explain the cause in detail. When Ctrl+F is pressed, an input box
is opened in the application and Fcitx5 creates a new virtual keyboard
(VK), whose initial modifiers is empty. Then prior to 683f67b7, the
key/modifiers events flowed like this:
- The compositor detects F key-release
- Modifiers (Ctrl pressed) are notified via _set_keyboard()
- F key-release is forwarded to IM
- IM sends modifiers (Ctrl) back to the compositor via VK
- **The modifiers on VK is updated (empty->Ctrl)**
- **Modifers (Ctrl) are notified to the app**
- IM sends F key-release back to the compositor via VK
- F key-release is notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is forwarded to IM
- Modifiers (empty) are forwarded to IM
- IM sends Ctrl key-release back to the compsitor via VK
- Ctrl key-release is notified to IM
- IM sends modifiers (empty) back to the compositor via VK
- **The modifiers on VK is updated again (Ctrl->empty)**
- **Modifiers (empty) are notified to the app**
Thus, the final modifiers (empty) is notified to the application as
expected. However, after 683f67b7, the key/modifiers events flowed like
this:
- The compositor detects F key-release
- F key-release is directly notified to the app
- The modifiers (Ctrl) is also notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is directly notified to the app
- Modifiers (empty) are forwarded to IM
- IM sends modifiers (empty) back to the compositor via VK
- **Modifier on VK is not updated (empty->empty)**
- **The compositor ignores it**
So the final modifier (empty) is never notified to the application, which
causes stuck Ctrl modifier.
This commit fixes this by not forwarding the modifiers when it hasn't been
updated since it was forwarded previously. So after this commit, the
key/modifiers events flow like this:
- The compositor detects F key-release
- F key-release is directly notified to the app
- The modifiers (Ctrl) is also notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is directly notified to the app
- The modifiers are directly notified to the app because the modifiers
(empty) are the same as the last forwarded modifier (empty).
On reconfigure, we should send wl_pointer.{leave,enter} events if the
cursor is on an application surface to let the application update the
cursor, but bad788cc prevented these events from being sent.
Before this commit, keystrokes were interpreted based on following
hard-coded rules while the window switcher is active:
1. Up/Left arrow keys cycle the window forward.
2. Down/Right arrow keys cycle the window backward.
3. Other keystrokes cycle the window in the initial direction specified
by NextWindow/PreviousWindow actions. But while Shift key is pressed,
the direction is inverted.
...and keybind actions were never executed.
However, this lead to a counter-intuitive behavior for new, especially
pre-Openbox users. For example, in the following keybinds, after the user
activates the window switcher with Super+n, Super+p cycles the window
_forward_:
<keybind key="W-n">
<action name="NextWindow" />
</keybind>
<keybind key="W-p">
<action name="PreviousWindow" />
</keybind>
This is because the key 'n' is recognized just as a normal key in the
third hard-coded rule.
So this commit changes the rules to be more Openbox-like:
1. Up/Left arrow keys cycles the window forward.
2. Down/Right arrow keys cycles the window backward.
3. Other keystrokes are matched against keybinds and execute their
actions. If they include NextWindow/PreviousWindow action, it cycles
the selected window forward/backward even while the window switcher
is active.
Currently we may end up in an endless loop of Reconfigure requests
if the Reconfigure action was called by a keybind. If the reconfigure
takes too long (which may happen on slow systems with libsfdo full
debug logging for example) the reconfigure might be triggered again
and again.
To prevent that, simply cancel all keybind_repeat timers on reconfigure.
This commit cleans up the comments and cruft from e45fe08.
Background:
- With e45fe08, the keyboard focus is always moved to the switched window
on finishing window switcher, even with <focus followMouse="yes">.
Since followMouseRequiresMovement was not implemented at that time
(behaved like it was always "no"), e45fe08 was necessary to allow users
users who use followMouse="yes" to move the keyboard focus with window
switcher.
- 9a9e20d added followMouseRequiresMovement, but it kept the behavior
described above even with followMouse="yes" and
followMouseRequiresMovement="no".
- 398b80b accidentally invalidated e45fe08, which means the keyboard focus
is now always moved to the window below the cursor on finishing window
switcher with followMouse="yes" and followMouseRequiresMovement="no".
Although the invalidation was a accident, I think always setting the
keyboard focus on the window below the cursor is what users expect from
followMouse="yes" and followMouseRequiresMovement="no".
The previous revert fixed the problem of stuck modifier keys with
keybinds in Blender, but made Firefox show its menu bar with Alt-*
keybinds. This is fundamentally inevitable due to the limitation of
wayland protocol, but at least for the default Alt-Tab keybind for
window switcher, we can mitigate this problem by clearing the keyboard
focus when the window switcher is activated. This is what KWin does, and
we decided to follow that.
So in this commit, keyboard and pointer focus are temporarily cleared
while Move/Resize, window switcher and menu interactions and restored
after them. We slightly deviate from KWin as KWin doesn't clear the
keyboard focus while Move/Resize, but it solves our existing problem
that Firefox shows its menu bar after dragging it with default Alt-Drag
mousebind, and this is what Mutter does.
We considered other solutions, but they don't work well:
1. Send wl_keyboard.{leave,enter} every time keybinds/mousebinds are
triggered. This solves the Firefox's menu bar problem, but that
sounds like a workaround and sending unnecessary events every time is
not desirable.
2. Send release events for both modifiers and keys even when they are
bound to keybinds. This is what Mutter is doing, but it looks like an
implementation issue and violates wayland protocol.
Before this commit, the pointer focus is cleared when a menu is closed
by clicking its border. This is because get_cursor_context() returns
type=LAB_SSD_NONE when the cursor is on the menu border and
cursor_update_common() clears the pointer focus. This commit fixes this
by replacing cursor_update_common() with cursor_update_focus(), which
calls get_cursor_context() again after the menu scene-node is hidden.
After commit e2189903 in wlroots, when ctrl-f is pressed in firefox with
a IME client running, the following key-release event for "f" is not
sent, thus "f" is repeated like "ffffffffff..." in the input box of
firefox. This is because the key-release event for "f" is firstly
forwarded to the IME client and then sent via the virtual keyboard created
by the IME client while the key-press event is sent via physical
keyboard, and with e2189903, key-release events without a corresponding
key-press event on the same keyboard is not emitted to the compositor.
So this commit fixes this problem by not forwarding the key-release event
to the IME client unless the corresponding key-press event was also
forwarded.
