Key events associated with keybindings (both pressed and released) are not
sent to clients. When using wlr_seat_keyboard_notify_enter() it it
therefore important not to send the keycodes of _all_ pressed keys, but
only those that were actually _sent_ to clients (that is, those that were
not bound).
This approach is consistent with sway's implementation in input/seat.c
cffb006feb/sway/input/seat.c (L173-L175)
Fixes issue #510
Call key_state_set_pressed() before checking
seat->active_client_while_inhibited to avoid missing release events for
clients using the inhibit protocol (for example swaylock).
If a user lets go of the modifier (e.g. alt) before the 'normal' key (e.g.
tab) when window-cycling, we do not end the cycling until both keys have
been released. If we end the window-cycling on release of the modifier
only, some XWayland clients such as hexchat realise that tab is pressed
(even though we did not forward the event) and because we absorb the
equivalent release event it gets stuck on repeat.
Just to clarify the position here: Issue #176 describes a behaviour
whereby dmenu gets stuck on repeat after being launched with a keybind.
This patch does not resolve that issue but reflects that in Wayland, the
client is responsible for implementing "key repeat".
Changing the key repeat rate/delay in (labwc/labwc@e62bb51) was dirty fix
that need should never have been made.
This fixes an issue with the wlr_output_cursor not being properly
initialized on new outputs, because wlr_output_layout.events.change
is triggered too soon, before the wlr_output_cursor exists.
Stack trace:
#0 xkb_keymap_ref (keymap=keymap@entry=0x0) at ../libxkbcommon/src/keymap.c:61
#1 0x00007f53a344ab99 in wlr_keyboard_set_keymap (kb=kb@entry=0x5571af8cb9a0, keymap=keymap@entry=0x0)
at ../types/wlr_keyboard.c:174
#2 0x00005571ade057e0 in keyboard_init (seat=0x7ffca0389680) at ../src/keyboard.c:229
#3 seat_init (server=0x7ffca0389570) at ../src/seat.c:307
#4 server_init (server=0x7ffca0389570) at ../src/server.c:308
Attempting to open a GTK3 menu and activate a menu item in it,
using a single mouse motion (press-move-release), was broken due
to GTK apparently expecting to receive leave/enter events when the
cursor enters the menu (XDG popup).
To fix the issue, allow leave/enter events when the cursor is
moved between an XDG toplevel and popups of the same.
v2:
- Use (struct view *) as proxy for toplevel in comparisons
- Update seat->pressed.surface when entering/leaving popups
v3:
- Go back to using get_toplevel() rather than (struct view *)
Fix a couple of glitches seen when exiting interactive move/resize:
- Cursor briefly set to left_ptr rather than the correct cursor image
- Cursor not updated if the view being moved/resized is destroyed
Also make sure to exit interactive mode if the view is going fullscreen
(labwc gets very confused otherwise).
Code changes in detail:
- Factor out set_server_cursor() which will set the correct cursor
image for non-client areas (either XCURSOR_DEFAULT or one of the
resize cursors).
- Unify the logic from cursor_rebase() and process_cursor_motion by
factoring out cursor_update_common(). This corrects some logic
discrepancies between the two, which should be a good thing(TM).
- Remove the extra cursor_set(XCURSOR_DEFAULT) from interactive_end()
and instead rely on cursor_update_focus() to do the right thing.
- Simplify cursor_button() by just calling interactive_end() when we
want to exit interactive mode.
- Call cursor_update_focus() from view_destroy() if the view had mouse
focus or was being interactively moved/resized.
v2: Eliminate force_reenter parameters and figure out automatically
when we need to re-enter the surface.
v3: Rename wlseat -> wlr_seat.
v4: Simplify client/server cursor logic.
Corner buttons (WINDOW_MENU and CLOSE) are one more level down in
the scene-tree (see add_scene_button_corner() in ssd_part.c).
This fixes a minor issue where, when right-clicking on the CLOSE
button, the client-menu would be displayed in the wrong location.
... and use Title for the Drag (Move) and DoubleClick (Maximize)
titlebar actions, which are unexpected when the cursor is over one
of the window buttons.
