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
When a button is held down and the cursor leaves a surface, events now
continue to be sent to the client. This allows e.g. dragging a scroll
bar from outside the surface.
- 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.
We don't rearrange the layout on fullscreening a view that is part of
the layout since the fullscreened view hides the layout. This means that
if a non-floating fullscreen view is closed the layout needs to be
rearranged.
When a floating view is returned to the layout or made fullscreen, it
now saves the dimesions it had while floating and returns to that same
position/size if made to float again.
Transactions are only useful when multiple views need to atomically
change size together. Float/fullscreen views are independant of the
layout and should bypass the transaction system.
