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.
...of modifiers which are part of keybinds. This supports clients (for
example blender) that want to see modifier-release-events even if they are
part of a keybinds.
Most clients (including those using Qt and GTK) are setup to not see these
modifier release events and actually misbehave if they do. For example
Firefox shows the menu bar if alt is pressed and then released, whereas if
only pressed (because the release is absorbed) nothing happens. So, if
Firefox saw bound modifier-release-events it would show the menu bar every
time the window-switcher is used with alt-tab.
<windowRules>
<windowRule identifier="blender" wantAbsorbedModifierReleaseEvents="yes"/>
</windowRules>
Issue #1507
...to all clients rather than just the one with keyboard focus on keyboard
enter/create, modifer press/release and wlr_seat_set_keyboard().
This enables:
- Clients such as panels to display the current keyboard layout without
introducing new wayland protocols or other IPC.
- Unfocused xdg-shell clients to understand button press with keyboard
modifiers for example Ctrl+click.
The keymap is forwarded to all clients in wlr_seat_set_keyboard(). When a
keymap contains multiple layouts, the selection is made via modifiers,
which previously were only sent to the client with keyboard focus.
Tested with: https://github.com/johanmalm/keyboard-layout
Ref: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4496Fixes: #2271
When `wlr_seat_pointer_notify_button()` is called on a button press event,
that funtion must also be called on the subsequent button release event
because otherwise wlroots thinks the button is kept pressed and it
causes issues with validating DnD requests from clients, where only one
button must be pressed. This was the case when a CSD client opens a
client-menu via `show_window_menu` request after pressing its window with
the right button because we were always not notifying button release
events while a menu is open.
So let's keep track of bound (pressed but not notified) buttons and notify
button release events only when the button is not bound, like we are doing
for key-state.
For `Drag` mousebinds, `pressed_in_context` is set by
`cursor_process_button_press()` and cleared by `cursor_process_motion()`
which runs actions bound to them. However, when `cursor_process_motion()`
is called while interactive move/resize, it doesn't clear
`pressed_in_context` due to the early-return and the `Drag` mousebinds are
unexpectedly executed on another call to `cursor_process_motion()` after
the interactive move/resize is finished by button release, even when the
button is not pressed.
So this commit fixes it by always clearing `pressed_in_context` on button
releases.
Before this commit, we assumed `ShowMenu` action is not bound to any
buttons other than window menu button and always place the client-menu
under the window-menu button when atCursor="no". Also, it was going to be
difficult to distinguish whether the action is executed from the window
menu button or the window icon, which will be added soon.
This commit fixes it to open the menu under the actually-clicked button by
passing `cursor_context` to `actions_run()`, with some refactoring:
- `seat->pressed.resize_edges` is removed and it's calculated from the
cursor position and `seat->pressed.type` just before running Resize
action. This slightly changes the existing logic to determine the
resizing edges with Alt-Right + Drag mousebinding, but
`seat->pressed.type` is still stored on button press so it doesn't bring
back the issue #543.
- `seat->pressed.toplevel` is removed and `get_toplevel()` in
`update_pressed_surface()` may be called more often, but its overhead
will be negligible.
When labwc un-tiles views, it generally changes their size, which sends
a configure request to the client. However, because the view has been
disabled in the wlroots scene, it will not receive and process the
configure when labwc expects. Instead, the handling will be deferred
until the user unshades the view at some arbitrary time in the future,
resulting in labwc registering complains like
[../src/xdg.c:239] client did not respond to configure request in 100 ms
Furthermore, the reconfigure will still generally produce flicker (as
the view opens in its tiled size and then jumps to its natural
geometry). Because skipping the unshade might cause client problems and
doesn't eliminate the problem it sought to resolve, let's revert this.
This reverts commit 2e19bd4d5b.
Applies drag resistance unidirectionally for horizontally/vertically
maximized windows, allowing them to be dragged without being untiled
immediately. When the distance of cursor movement orthogonal to the
maximized direction exceeds <resistance><unMaximizeThreshold>.
While dragging a horizontally/vertically maximized window, edge/region
snapping is disabled to prevent unintentional snapping and overlays.
This commit also includes some refactoring to simplify the logic.
Contrary to the raw tablet events, the cursor events transform
the coordinates based on a mapped output orientation.
Otherwise those events are the same.
...when cycling windows. Also make the toggling of direction when shift
is pressed relative to the initial direction. For example if W-j is
bound to PreviousWindow, subsequent key presses will continue to
cycle backwards unless shift if pressed.
Add documentation for using shift/arrow keys in Next/Previous
