It didn't occur to me that this is a completely valid case when a key
release event is received even though there was no press event known
to river.
(I've also just had this same crash on something else, but i don't
understand what the cause could be.)
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.
It is not unusual to see people coming to river directly from X11,
confused by some things being renamed (and by river having tags). Give
them some basic help for reading the manpage and understanding our talk.
Try to fix -h and -version. Remove seemingly superfluous -x everywhere,
only use one -f. Use -o for options. Update input devices listing.
Deduplicate some args. Try to do better for rule-add and rule-del.
Previous order was (action, conditions, action argument), current is
(conditions, action, action argument). The old one was an expansion of
(action, conditions), which itself most likely came from the separate
<action>-filter-add commands. On the other hand, the new order keeps
action and its argument together and is in line with the logical flow
(check conditions, apply action).
On shell completions: only bash absolutely needed to be updated. fish
and zsh slightly misbehave regardless of the order.
This goes as close as possible to the behavior before this state was
introduced (keeping the improvement which needed it, 931405ab), fixing
various mis-interactions of keyboard and focus_follows_cursor focus
changes.
The following text is irrelevant to restoring correct basic FFC behavior
and talks about less common scenarios with regards to FFC clashing with
views' input region beyond their geometry, continuing the work done in
931405ab.
Scenario 1: the cursor traveling along a view's border in a "dead zone",
never initiating a focus change. If the focused view has an extended
input region, that area has some functionality (such as client-initiated
resizing); therefore it should be respected and even if another view's
geometry is also under the cursor, focus shouldn't change. In case of
unfocused views, it is a matter of consistency with the focused-view
case. This outcome is also easier to implement, as it doesn't require
any additional code.
Scenario 2: *clicking* such a dead zone, i.e. extended input region (of
an unfocused view). In question is not whether to focus the view (yes),
but whether the focus_follows_cursor_target should be set to the view as
well. Only one case seems relevant to me here, which is when ffc_target
is another view whose geometry is under the cursor, but covered by this
newly-focused view's input region. The most likely action following the
click is resizing the newly-focused view, where a touchpad or faulty
mouse could make the cursor move a bit farther after the button has been
released. I believe that ffc_target shouldn't have been updated, in
order to now prevent focus from skipping away.
(Another variant is me, wondering why the wrong view got focused and
trying to focus the right one using FFC. In that case, however, one
could ask if it's river that misbehaves and whether the application is
really well-integrated into the user's desktop when it provides a
feature they don't desire.)
Not decreasing the counter caused a weird bug where disabling/removing
an output (curiously, it seems to apply only to last active output being
removed) would lock the user out of the session, not letting the
transaction to complete (therefore hiding all views on a newly added
output) and messing up focus.
Fixes https://github.com/riverwm/river/issues/830
As discussed with ifreund on irc. This avoids extra allocation in case
of all_outputs and confusion in case of active_outputs (because with the
Output embedded in the Node, i thought its value was copied instead of
its pointer).
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.
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).
I have encountered a crash (failing assert) if a view specified a fixed
size less than this minimum, and according to ifreund this behavior was
planned to be removed, anyway.
tiosgz