It is possible for the assertion in PointerConstraint.confine() to fail
if a view with an active pointer constraint is, for example, resized
using a keybinding such that the pointer is outside the constraint
region.
Handle this edge case by deactivating the constraint. The other option
would be to warp the pointer to the nearest point still inside the
constraint region. Deactivating the constraint is far simpler however
and I don't expect this to be a UX pain point.
Currently river only sends the fullscreen state to a maximum of one
toplevel per output at a time and switching tags such that the
fullscreen toplevel is not visible causes the fullscreen state to be
removed.
This may be technically correct, but it causes issues when programs like
firefox trigger animations on fullscreen state change.
This commit returns river's policy here to what we did back in 0.2 and
leaves the xdg_toplevel fullscreen state set regardless of whether or
not the toplevel is currently rendered as fullscreen or if there are
other fullscreen toplevels.
This fixes possible assertion failures when quickly cancelling and
starting a new move/resize. The following steps, take from the bug
report, can currently reproduce the race:
1. Start with a window in tiled mode.
2. Begin resizing the window with your cursor.
3. Send the window back to tiled mode (with a keybind) and quickly begin
resizing it again with your cursor.
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.
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.
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.
- Fix some completions that never really worked correctly, e.g `riverctl
input` didn't take the input name into account. Same with rule that
didn't take into account glob.
- Add a lot of documentation to help people adding new commands.
- Add new rule-[add|del] order.
- `riverctl input` now autocomplete input name from `riverctl
list-inputs`
This means that interactive resize speed is no longer throttled by the
speed at which the client commits new buffers. Interactive resize speed
is now determined entirely by how fast the pointer input device is moved
by the user.
This may result in more subjectively "choppy" resizes for clients that
commit very slowly, but it should be less sluggish at least.
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).
This was accidentally removed in 05eac54b077, which broke
SceneNodeData.fromSurface() for xdg_toplevels.
This means that thing such as xdg-activation and idle inhibit didn't
work since that commit and should work again starting from this commit.
When sending a configure, wlroots will send the same size that was sent
on the previous configure unless a new size is set. If a client resizes
their window itself, the size wlroots has in
XdgToplevel.scheduled will be obsolete and needs to be updated by river.
The previous commit broke handling of keyboard interactive
layer surfaces being created on multiple outputs at once.
This new approach reverts part of the logic change in the previous
commit while keeping the fix for the crash and the new assertion.
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.
This eliminates cursor jitter entirely during interactive resize.
This also fixes a bug where the xdg-toplevel resizing state was not
cleared if a resize operation was aborted due to a change in view tags
or similar.
Some clients (e.g. mpv) do not respond to configures by committing
buffers of the exact size requested. Instead they may commit a buffer of
a smaller size in order to maintain an aspect ratio or not commit a
buffer at all.
Mixing views that are currently being mapped/unmapped with views that
are stashed during hotplug down to 0 outputs is error-prone and almost
certainly has a bug or two hiding currently.
If a output is removed and added back without being destroyed this must
be reinitialized.
This commit also cleans up the Root.applyPending() calls related to
output hotplug and adds some more logging.
