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
Rename wlroots input device events, for example
's/wlr_event_pointer_motion/wlr_pointer_motion_event/'
seat.c:
- In configure_libinput() use wlr_input_device->type rather than width_mm
- In new_pointer() use wlr_input_device->type rather than output_name to
check that device is pointer.
<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
If we don't switch focus, we want the close button to close the window associated with it, not the current focus window.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Split desktop_focus_view() into the following two functions:
- desktop_focus_and_activate_view()
- desktop_raise_view()
Always call view_set_activated() rather than using the private
set_activated(). This keeps the code cleaner and ensures
wlr_foreign_toplevel_handle_v1_set_activated() is called.
Change the code that detects when to stop cycling the view,
so that instead of looking for the left Alt key release it
looks for all modifiers released (thus. will work whether you
have this action bound to Alt-Tab, C-Tab, Meta-Tab, etc)
To do this we move the test from keyboard_key.notify to
the later signal keyboard_modifiers.notify, because the xkb_state
has been updated by then and the modifier state will be
accurate
