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
...in support to specifying 'left', 'right' and so on with actions
GoToDesktop and SendToDesktop.
For example:
<mouse>
<default/>
<context name="Desktop">
<mousebind button="Up" action="Scroll">
<action name="GoToDesktop" to="left"/>
</mousebind>
<mousebind button="Down" action="Scroll">
<action name="GoToDesktop" to="right"/>
</mousebind>
</context>
</mouse>
Since xwayland commit 9e4b7948df5a9a67632bb606150ec171b5519672
there is a one-second delay between XWayland surfaces being
unmapped and destroyed. This revealed that we were not actually
handling the unmap() signal correctly for unmanaged surfaces.
...to the pid of the compositor so that SIGHUP and SIGTERM can be sent to
specific instances using `kill -s <signal> <pid>` rather than
`killall -s <signal> labwc`
Issue #573
@Consolatis determined that apparently the extra "clear focus"
event confuses the drag source during drag-and-drop.
Fixes drag-and-drop of files into folders within the same Thunar
window.
...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.
On initial positioning of toplevel windows we call view_center().
During the centering process, if it turns out that the view is larger than
the output usable-area then we just top/left align it with no gap.
Relates to the gap aspect of issue #403
Reported-by: @Flrian
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
