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.
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.
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.
This is a breaking change and replaces the previous
csd-filter-add/remove and float-filter-add/remove commands.
See the riverctl(1) man page for documentation on the new system.
How river currently sets this isn't really in accordance with the spirit
of the protocol. It was originally done this way to get gtk3 windows to
look a little bit better with borders drawn around them. However, I've
come to believe that river shouldn't just ignore standards like this.
The right way to do things would be to either implement the
xdg-decoration protocol for gtk properly or to be pragmatic and accept
some programs are intended to be used with CSD and that's OK.
This brings the behavior closer to what we had before the scene
graph refactor.
The main difference now is that the order has changed from background to
overlay instead of from overlay to background. This ordering seems to
make more sense in the cases I've tested and the old ordering was just
cargo-cult anyways.
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.
This replaces the old View.fromWlrSurface function and is more general.
This commit also moves the xdg activation request_activate listener to
Server as it has no reason to be in View.
This is more reliable since it uses absolute coordinates instead of a
relative movement which could cause the cursor position to get out of
sync with the view.
This is the same approach used for resize.
- Move the decision whether a configure should be tracked or not into
the xdg toplevel/xwayland code.
- Only track configures for xdg toplevels with the transaction system
if the dimensions of the view are affected.
Currently we may resize fullscreen views when they become visible/not
visible when switching tags even if their fullscreen state remains
constant. This is suboptimal, and as it turns out also much more complex
to implement.
We need to initialize the geometry on map to ensure the first commit is
handled correctly.
Also we don't care about the x/y of the geometry, only the width/height.
In commitTransaction() we currently the current view state to determine
whether or not to enable the view's scene tree. However we don't update
the view's current state until after that check.
Moving fullscreen views between outputs now works properly.
A case in which we did not inform the client that it is no longer
fullscreen has been fixed as well.
The race is as follows:
1. Output A commits and sets render state to pending_lock_surface
2. Output B commits and sets render state to pending_lock_surface
3. Output A presents and sets render state to lock_surface
4. maybeLock() does not lock because waiting on output B
5. Output A commits and sets render state to pending_lock_surface
6. Output B presents and sets render state to lock_surface
4. maybeLock() does not lock because waiting on output A
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.
It looks like having the empty error capture |_| on the else branch of
the if statement causes the else branch to be ignored by the compiler.
This should be a compile error, as the condition of the if statement is
a bool, not an error union.
These new functions allow testing commits without messing up the
pending state of the output and needing to rollback. The new apply()
function also makes the code considerably more concise.
A user reported a crash that only reproduces when preloading a hardened
malloc implementation. From the stack trace, this use-after-free seems
to be the most likely cause. Yay hardened malloc!
Outputs that are part of the layout but currently disabled (e.g. due
to use of wlr-output-power-management) are not correctly handled as
river currently waits for them to present a new locked frame before
sending the locked event.
This new frame never comes however since the output is disabled. Fix
this by maintaining the correct Output.lock_render_state as outputs
are enabled/disabled.
Additionally add missing maybeLock() calls to handle the case that all
outputs in the layout are disabled.
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.
Isaac Freund