Commit graph

4 commits

Author SHA1 Message Date
Johan Malm
20c4ffa539 src/keyboard.c: do not end window-cycling on modifier release only
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.
2022-09-21 21:25:13 +01:00
Johan Malm
a363f73e02 Revert "keyboard: cancel repeat when handling key-bind"
This reverts commit e62bb51bfb.

Fixes #510
2022-09-20 20:52:48 +01:00
Johan Malm
e62bb51bfb keyboard: cancel repeat when handling key-bind
<keybind key="W-d">
  <action name="Execute">
    <command>dmenu_run</command>
  </action>
</keybind>

When using the keybind above (in rc.xml), on the first execution of W-d
all is okay, but the second time, a "d" pressed event is sent to dmenu
resulting in a continuous "ddddddd...") which has to be stopped pressing a
key.

This behaviour started in commit 7e57b7f because release events associated
with keybinds are no longer sent to clients (before that commit, the
release event for the “d” would have been passed to dmenu, thus cancelling
the repeat).

Solves issue #176

Helped-by: @spectrum70
2022-01-02 15:28:35 +00:00
Johan Malm
7e57b7fcf5 keyboard: absolve release event if press was bound
When key press events are handled by compositor keybindings, do not
forward the corresponding release events to clients.
2021-12-22 10:37:25 -05:00