Previously new keyboards would not be added to already existing
keyboard groups on (re-)connect. Only during the creation of
the groups themselves were devices added to them. This meant
that only keyboards connected during startup - before the init
is executed - would work with groups in a typical river session.
This code could allows the view to be focused and urgent at the
same time if the request to activate the view is received just after
the pending focus has been set but before the transaction completes.
This commit leverages the new wlr_scene helper to send custom feedback
per surface rather than using the same default feedback for every
surface. This should allow direct scanout to work more reliably with
multiple outputs for example.
wl_drm is a legacy interface superseded by the linux-dmabuf
protocol. All clients should migrate.
This commit drops support for the protocol which should help find
whatever problematic clients are left in the wild.
If it turns out that this is too soon we can easily keep supporting
wl_drm for a little while longer as wlroots has not yet dropped support
for it.
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 wlr-output-management config application is broken since the
pre 0.17 code relied on the (now removed) output enable/disable event to
be emitted as part of the state application.
The old code was pretty smelly and hard to understand, I'm glad the
upstream improvements pushed river's code in this directions.
Thanks to tiosgz for prompting me to look at this more closely.
There doesn't seem to be any compelling reason to use the
wlr_scene_output_layout helper, it's simpler to just make the two
necessary SceneOutput.setPosition() calls manually. This will hopefully
be refactored down to a single call eventually as well.
This logic that looked pointless to me while doing the wlroots 0.17
upgrade is in fact important as tiosgz helpfully pointed out.
It was added back in bc610c8b to address an issue. Hopefully the new
comments stop me from trying to break it again :)
The previous commit ended up clamping the accumulated f64 offset to an
integer every frame, losing any sub-pixel cursor motions. This has been
known to cause problems with high polling rate mice in the past.
Return to the same approve the move cursor mode uses to solve this and
accumulate a separate sub-pixel delta.
Currently resizing a window allows moving the invisible "internal"
cursor infinitely far off screen despite the fact that the window is
bounded by the size constraints of the client and by the output
dimensions. This means that attempting to resize past these bounds in
one dimension will result in the "internal" cursor being far out of
bounds and will require an equal movement in the opposite direction in
order to continue resizing.
Exposing this implementation detail of an invisible "internal" cursor
separate from the rendered cursor is of course bad, so clamp it to the
bounds of the resize.
Currently views which are mapped while no outputs are available can
never actually get rendered because they have 0 tags and are stuck in
the hidden stack.
This commit fixes this and they should now be restored when a new output
becomes available.
Such requests currently lead to an assertion failure.
I don't know what changed in nautilus 45.0 that caused it to start doing
this and I probably don't want to know.
This rule action accepts and assigns a set of 32 tags represented as a
32 bit integer just like all of river's other commands handling tags.
Using the singular here is potentially misleading and is also
inconsistent with set-view-tags, etc. which all use the plural.
Sorry about the breaking change for those who use master branch, ideally
I would have caught this before merging but at least I noticed before a
release.
This commit also does a bit of internal refactoring/cleanup of the rules
system.
This commit adds a fullscreen rule for configuring
whether the view should be drawn fullscreen on start up.
The actions "fullscreen" and "no-fullscreen" map to the two
possible state of a view and semantically operate on the same
rule list. The behavior of adding, deleting and listing rules
follows that of float and ssd.
This commit adds position and dimensions rules for configuring
the initial position and dimensions of views.
When a view is not matched by any position rules, it is centered
in the avaliable output space matching the current behavior. If
the provided position rule places the view outside of the output,
the view's position is clamped to the output bounds (with respect
to borders).
When a view is not matched by any dimensions rules, no default
dimensions is set by the server. If the provided dimensions rule
exceeds the minimum or maximum width/height constraints of the view,
the view's width/height is clamped to the constraints.
Position and dimensions rules have no effect if a view is started
fullscreen or is not floating. A view must be matched by a float
rule in order for them to take effect.
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.
