Deprecate and ignore the riverctl commands for creating explicit
keyboard groups.
In my mind, the only reason to have more than one keyboard group is if
different keyboard devices are assigned different keymaps or repeat
rates. River does not currently allow such things to be configured
however.
When river eventually makes it possible to configure different keymaps
and repeat rates per keyboard device, there is no reason we can't 100%
automatically group keyboards based on the keymap/repeat rate.
Exposing this keyboard group abstraction to the user is just bad UX.
Failing to group keyboards automatically also creates confusing/buggy
behavior for the user if the hardware, for example, exposes some of the
the XF86 buttons on a laptop as a separate keyboard device from the main
keyboard. Creating keybindings for these XF86 buttons that use modifiers
doesn't work by default, but there's no reason it shouldn't just work.
Closes: https://codeberg.org/river/river/issues/1138
(cherry picked from commit 46f77f30dc)
Currently keyboard focus is stolen from layer surfaces with
on_demand keyboard interactivity any time Root.applyPending() is called.
This commit fixes the behavior to only steal focus when explicitly
focusing a different window/layer surface.
(cherry picked from commit 4232d6b99f)
Currently if a second keyboard input device is created river will send
a wl_keyboard.leave event immediately followed by a wl_keyboard.enter
event. This serves no purpose and can confuse clients, in particular due
to fctix creating/destroying virtual keyboards on focus change.
Fixes: https://codeberg.org/river/river/issues/1062
References: https://github.com/fcitx/fcitx5/issues/1044
(cherry picked from commit 1e3ef88bd5)
Currently if a second keyboard input device is created river will send
a wl_keyboard.leave event immediately followed by a wl_keyboard.enter
event. This serves no purpose and can confuse clients, in particular due
to fctix creating/destroying virtual keyboards on focus change.
Fixes: https://codeberg.org/river/river/issues/1062
References: https://github.com/fcitx/fcitx5/issues/1044
There is not any pointer emulation for tablet tool input. This means
that only clients implementing the tablet-v2 protocol will be able to
process tablet tool input.
Tablet pad support is TODO
wlroots implements this behavior with its key press tracking but
continues to forward the events to the compositor. Matching the wlroots
behavior here seems like the best way to avoid strange edge cases and
this is unlikely to ever be an annoying limit in practice.
Also take this oppurtunity to finally refactor away the hasMapping()
function in a way that doesn't sacrifice correctness even when hitting
this 32 key press limit.
The old eat/pass-on point of view was good when there was only the
focused client to send the key to. But where does the input method
stand? Instead, we now want to know where the key goes, treating river
and clients all equally.
Thanks to ifreund for pointing me to std.BoundedArray which simplifies
some of the logic.
To see why this is needed, compare the following flows:
- user: press key 'j' with Super already pressed
- Keyboard: handle mapping, focusing next view
- Seat: send wl_keyboard.enter with keys Super and 'j'
- Keyboard: eat key 'j'
versus:
- user: press key 'j' with Super already pressed
- Keyboard: eat key 'j'
- Keyboard: handle mapping, focusing next view
- Seat: send wl_keyboard.enter with key Super.
The necessity of this was already mentioned in 1e3b8ed1; however,
without a comment in code, it was removed in 393bfb42 as superfluous.
Hopefully, the newly added comment will prevent such mistakes in the
future.
Fixes https://github.com/riverwm/river/issues/978
As noticed by leon-p, last refactorings made river send a release event
to the client even if the press event has been eaten. In addition, the
introduction of input method support means that we need to remember
*why* we've eaten the key.
Also make KeycodeSet more strict: i am not aware of any case when a
keyboard could have the same key pressed twice (specifically, keyboard
groups have this handled in wlroots), so make the behavior follow a
smaller set of possible scenarios.
If our current approch without xkbcommon translation does not match any
mapping on a key event attempt to match the translated keysym as well.
This makes e.g. the keypad number keys (e.g. KP_1) work intuitively as
they may require translation with numlock active.
The reason we stopped doing this in I7c02ebcbc was due to layout where
e.g. Super+Shift+Space is translated as Space with the Shift modifier
consumed, thereby conflicting with a separate mapping for Super+Space.
This should not be a issue anymore though as we now only run a maximum
of one mapping per key event and we attemt to match mappings without
xkbcommon translation before attempting with translation.
The protocol states that we must send enter and leave to all text input
objects if the client has created multiple.
Only one text input is allowed to be activated by the client per seat
however.
Currently if a drag icon is created but the cursor/touch point is not
moved river will render the drag icon at 0,0 instead of the cursor/touch
point location. This fixes that.
Currently if a layer surface is focused and the user focuses a different
output the layer surface remains focused. However, updating focus on
layer surface unmap only considers seats that have the layer surface's
output focused.
To fix this there are 3 approaches I see:
1. Unfocus all layer surfaces on the old output when switching output
focus, focus any layer surfaces on the new output.
2. Disallow switching output focus while a layer surface is focused.
3. Stop caring about output focus when determining which layer surface
should gain/lose focus.
I've taken the 3rd option here as it is significantly simpler to
implement and maintain but still feels reasonably intuitive.
Now with 50% less pointer warping!
The new implementation requires the user to move the cursor into the
constraint region before the constraint is activated in order to keep
behavior more predictable.
The scene_layer_surface may be destroyed before handleDestroy is called,
which means we can't rely on it to access the wlr_layer_surface in
destroyPopups().
This implementation as it stands is incomplete/buggy and will make
updating to wlr_scene more complex.
It will be reimplemented after updating to wlr_scene is complete.
Instead of stashing the active view and setting Seat.focused to the
Xwayland OR surface when a child OR surface of a currently focused
Xwayland view is given keyboard focus, keep Seat.focused set to the
Xwayland view.
Such Override Redirect surfaces are commonly used for drop down menus
and the like, and river should behave as if the parent Xwayland view
still has focus.
This ensures that the riverctl focus-view next/prev commands continue to
work as expected while a popup is open, the correct focused view title
will be sent over river status, etc.
It's also cleaner to centralize this logic in XwaylandOverrideRedirect
and keep it out of Seat.zig.
Xwayland OR menus may disappear if their parent view is deactivated. The
heuristic and ICCCM input model implemented prior, used to determine whether an
OR surface may take focus, does not cover all menus, so retaining parent view
activation works as a catch-all solution for handling unwanted OR menu focus.
This is nice simplification and allows us to abort startup if the
default xkb configuration (perhaps influenced by XKB_DEFAULT_*
environment variables) is invalid.
