Make desktop_focus_view() always switch to the workspace containing the
view being focused. It doesn't make much sense for an invisible view to
have the keyboard focus.
Also add an optional "raise" parameter to desktop_focus_view(). This
allows the common pattern of desktop_focus_view() + view_move_to_front()
to be reduced to a single function call.
...and avoid failing to send release events to clients for any keys that were
not absorbed by a keybind.
Do not match keybinds if there are other non-modifier keys (not part of any
defined bind) pressed at the same time.
Only store non-modifier keycodes in the key-state.c 'pressed' array.
This makes the call to wlr_seat_keyboard_notify_enter() in seat_focus()
consistent with the equivalent in sway (in seat_keyboard_notify_enter()).
Fixes: issue #1091
Our current approach to handling the focused/active view is a bit
confusing. In particular, it's hard to be sure when server->focused_view
is or isn't in sync with the real wlroots keyboard focus.
Try to clean things up a bit. In particular:
- Add comments to server->focused_view and desktop_focused_view() to
clarify that they should match, but it's not guaranteed.
- desktop_focused_view() now prints a warning if it detects that
server->focused_view is out of sync. We should keep an eye out for
this warning, and if we see it, try to figure out why it happened.
- For consistency, use only "focus/defocus" as the verbs in function
names rather than "activate". This is a bit arbitrary, but the idea is
that focus is the primary action while the active/inactive state is a
side effect.
- view_focus/defocus() replace view_set_activated() and now update both
focus and active/inactive state, to try to keep them in sync.
- Add comments at view_focus/defocus() to warn against calling them
directly (we should generally call the desktop.c functions).
- desktop_focus_view(NULL) is now forbidden and is no longer handled as
a special case to clear the focus. This was (at least to me) a
surprising behavior and caused trouble when working on another change.
- To maintain existing behavior, desktop_focus_topmost_mapped_view() now
explicitly clears the focus if there are no mapped views.
There should be no behavioral change here.
When looking up keybinds, if the translated keysyms (based on the keymap
for the keyboard) do not match a defined keybind, try raw keysyms (as if
there were no modifier translation).
This allows a user to define for example keybind with "S-1" rather than
"S-exclam". It also supports "W-S-Tab".
Fixes: issues #163#365#992
The `wlr_keyboard.events.modifiers` signal does not use
a `wlr_keyboard_key_event` as argument, instead it is a
pointer to the `wlr_keyboard` instance which caused the
signal.
When wanting to snap to a region when starting the move
operation with A-Left (or a similar mousebind which includes a
modifier), the modifier - or another one - must be pressed again.
Fixes#761
This can be used to better control Virtual Machines, VNC clients, nested
compositors or similar. All keybinds other than ToggleKeybinds itself are
disabled when first called, a 2nd call will restore handling of all keybinds.
Fixes#738Fixes#810
...to increase xwayland and xdg-shell encapsulation and to avoid passing a
function pointer as an argument in `xwayland_move_sub_views_to_front()`
which is inconsistent with labwc design patterns.
Rename view-impl.c to view-impl-common.c
Move function declarations that are common to view-implementations from
view.h into view-impl-common.h
It seems that every Wayland client is expected to implement its own
key-repeat logic, rather than doing it server-side as in X11. This
means that labwc also has to implement its own key-repeat logic for
compositor keybindings.
This is a very simplistic timer-based implementation. It doesn't
attempt to synthesize accurate timestamps, and may lag depending
on system load, but it appears to get the job done.
v2: Use server->wl_event_loop
v3: Comments and formatting
...so that it can be determined what wlr_keyboard events come from.
This is required to manage virtual keyboards alongside the keyboard_group
of physical keyboards.
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.
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
