If the current Cursor.maybeResetState() function is called while in
passthrough mode, it will send a pointer motion event. This is
unnecessary as we have already sent the same pointer motion event at
least once.
Also refactor the code slightly and improve naming.
A transaction may move the current target of a cursor action to a
non-visible tag, make it fullscreen, or otherwise change things such
that the current cursor state no longer makes sense.
To handle this, check if we should reset cursor state every time a
transaction is committed.
This code is complex and increases maintenance burden but doesn't
add any functionality, only eye-candy.
Futhermore, neither I nor any of the core contributors use it.
There may be a place in river for such eye-candy down the line, in which
case this code could be revived. Currently river is early enough in its
development that our focus should be on core functionality instead.
A client is free to change its mind and request a different
size/anchor/etc after recieving the initial configure but before
attaching and committing the first buffer. This means that we should
respond to such a situation with a new configure.
mako has been observed doing this in the wild for example.
Currently in handleUnmap() we call View.unmap() before removing
listeners. However View.unmap() may destroy the view before returning
if the transaction started doesn't have to wait on any configures.
To ensure that we don't try to remove listeners which have already been
free'd, do this before calling View.unmap().
The Layout struct holds a pointer to the Output which becomes invalid
when the Output is destroyed so we must ensure all the layouts of an
Output are destroyed first.
Replace the current layout mechanism based on passing args to a child
process and parsing it's stdout with a new wayland protocol. This much
more robust and allows for more featureful layout generators.
Co-authored-by: Isaac Freund <ifreund@ifreund.xyz>
Recover more gracefully from being hotplugged down to 0 outputs and then
gaining a new one. Move all views to the new output and restore the
focused output tags of the last output to be removed.
There is now a single iter() function which accepts a filter and context
allowing users of the api to filter the views in any arbitrary way. This
change allowed for a good amount of code cleanup, and this commit also
ensures that the correct properties are checked in each case, including
the new View.destroying field added in the previous commit. This fixes
at least one crash involving switching focus to a destroying view.
Focus was made double-buffered in 96a91fd. However, much of the code
still behaved as if focus was separate from the transaction system.
This commit completes the work started in 96a91fd and ensures that
focus is applied consistently in a single transaction.
- require the caller to use Root.startTransaction() directly
- introduce View.applyPending() to unify logic
- introduce View.shouldTrackConfigure() to unify more logic
- update all callsites to intelligently rearrange only what is necessary
- Double buffering focus state ensures that border color is kept in sync
with the transaction state of views in the layout.
- Using a counter instead of a bool will allow for proper handling of
multiple seats. This is done in the same commit to avoid more churn in
the future.
This simplifies the handling of the current/pending tags and will be
used in the future for atomic layout updates involving layer surface
exclusive zones.
The state struct holds all of the state that is double-buffered and
applied through transactions. This more explicit handling simplifies
much of the code, and will allow for easier implementation of new
feature such as fullscreen.
river is not a library and passing a general purpose allocators around
everywhere does not make sense and leads to ugly code. This does not
prevent us from using local arenas if they are fitting.
