It is not guaranteed that the next layout_demand event after a user_command
event has the same active tags (for example when there are no views visible).
As an example, a user could trigger a user_command while no views are visible,
then switch to a different tag set which has active views. The active tags of
the previous layout_demand may also be different.
Therefore it is impossible to correctly implement a layout generator which has
user commands apply only to the currently active tag set, which is solved by
this patch.
When river or wlroots write to a closed socket it could generate SIGPIPE
causing the whole desktop to seemingly "crash" with no error log of any
kind. So we ignore the SIGPIPE and just let the write fail with EPIPE to
be handled normally.
Currently we don't send an enter event when a new keyboard device is
created which causes issues when switching ttys. On switching away the
keyboard device is destroyed and leave is sent. Currently on switching
back the keyboard device is re-created but no enter event is sent before
we start sending key events, which is a violation of the protocol.
In cases like multiple hi-res monitors connected through a USB dock, the
preferred mode can fail to work. Such an output was then ignored by river,
which made it impossible to even set another mode manually.
Sway has been reported to solve this issue, so let's employ their solution
and fall back to another mode if possible.
This fixes the return type of Foo.fromWlrSurface() functions which can
in fact return null in the edge case that the role matches but the
corresponding object has already been destroyed.
Still TODO are:
- Touch support for drags
- Mapping input devices to outputs (necessary for good multi-monitor
touch support)
Co-authored-by: Daan Vanoverloop <daan@vanoverloop.xyz>
Some popup menus are not covered by the `overrideRedirectWantsFocus()`
heuristic (e.g. in IntelliJ IDEA), so before focusing an OR window,
its input model should also be checked to ensure that it is able to
take input focus. This appears to fix the popup menus in IntelliJ IDEA,
which would otherwise disappear immediately due to unwanted focus.
- The lifetimes of the Keyboard and Switch structs are now directly
tied to the corresponding InputDevice, which has become a field of
those structs.
- Seat capabilities are now properly updated on removing a keyboard.
These changes align with input device refactoring in upstream wlroots
which will make updating to easier 0.16.0.
Currently we use "switch_device" because that's what the enum variant
happens to be named in zig-wlroots so that it doesn't conflict with the
switch keyword.
This however wasn't really thought through and "switch" makes more sense
to expose to the user.
This was removed a while back because it was buggy and I didn't know
of anyone using it. Since refactoring it is now trivial to implement
and I know of at least one person using it, so I don't mind reviving it.
Until now, Seat.setFocusRaw sent all pressed keys to the client,
including ones that should be eaten. (Try e.g. changing focus to a
nested wlroots compositor with a terminal open to easily see it.)
However, only filtering out the eaten keys is not enough; they were
eaten only once all mappings had been executed. Therefore, the original
function had to be split into one looking up mappings and another
executing them.
Until now, only the event (press/release) for which a mapping was
present got eaten, and the other was passed to the client. From this
commit, a press mapping eats both events and a release mapping eats
nothing (and a press+release combo eats both).
This fixes behavior of some clients that do not make a difference
between press and release (e.g. Firefox with a fullscreen video
exiting fullscreen even on an Esc release event).
Adding the set_override_redirect listener on creation and removing it
on destruction was missed when implementing override redirect state
change handling.
When checking keys for matching mappings, previously we did two checks:
1. Keysyms translated by xkb.
2. Raw keysyms
This commit removes the first check, so only the second is checked.
We're doing this because of strange behavior that xkb shows for some
layouts and keys. When pressing `Shift Space` on some layouts (Swedish
among others), xkb reports `Shift` as consumed. This leads to the case
that we cannot distinguish between `Space` and `Shift Space` presses
when doing a correct translation with xkb.
