We need to raise one of the focused window neighbours preemptively to get sane
focus after closing a window (ie. one of the neighbours should always get
focus).
However we also use the windows' stacking order to decide eg. which window in
a vertical tiling to select when entering from the side. Raising the neighbours
on focus can easily break this behavior, as the top window no longer is the most
recently selected.
If we use the clones stacking order instead we avoid these issues as it's
unaffected by the unavoidable window raising we do on focus.
When a new window is created from the overview [1], `display.focus_window` is
null. This broke our "should-window-be-scratch" logic.
Behavior observed both on X11 and wayland
[1] or the 'switcher' extension. Probably in general if a shell modal is active
when the window is created?
This covers scratch windows too.
Note: Specifically fixes a bug where 'tilix --quake' didn't work. tilix creates
a "on all workspaces windows" that was hidden in showHandler and never shown
again
Introduces `Space.addFloating` and `Space.removeFloating`. `startAnimate` and
`moveDone` takes care of showing the clone, syncing its position and hiding it.
This makes floating windows follow the workspace in the workspace carousel,
removing the rather ugly hack in `spaces.switchWorkspace` and simplifying
`showHandler`.
This makes selection logic a lot more centralized and robust. In particular the
selection highlight will now consitently track the window clone.
Also introduce `showWindow` `animateWindow` and `isWindowAnimating` to wrap some
potentially changing structure.
This fixes (mostly) issues with layout of constrained wayland windows.
eg. (* marks the selected window) slurp B:
layout
column A* B
...
resize of constrained window B finishes (before A)
trigger new layout (since target was not met)
`allocateDefault` strive to keep A's height (yet to be changed)
causing A to get all the height
We still have problems when the slurping the last window X (while X selected)
into a column with two constrained windows.
- We never request the window's _current_ size again
- Each time a resize is requested we mark the window with the targets
- These are cleared IF the request cause a resize
- Some windows are constrained and does not resize even when request != current
- Resizes can be async
This means that layout sometimes reach the state where:
currentSize != targetSize
targetSize == window's marked target
Happens when
a. An async window get a new size and a subsequent layout happens very quickly
(before the window is actually resized)
b. A constrained window is laid out and both its actual size and "layout
size" is unchanged from last layout.
Ie. we treat a constrained window as using infinite long time to fulfill a
request that is constrained to the window's current size.
(a) probably doesn't happen very often (?)
(b) is nice to avoid assuming such size-requests have a non-trivial cost.
It does assume that a constrained window always responds the same way to
requests for size S. Which obviously is not guaranteed. A window is free to
change its constraints at any time.
A constraint change due to changing discrete size increments will most
likely trigger a resize though - which will trigger a relayout.
And since we can't subscribe to constraint changes and layout isn't done on
every action it's not obvious that we want a constraint change to suddenly
become visible either.
The first async resize that completes cause a new layout which run using the
other async window's old size. This breaks layouts that request specific
heights (eg. slurp).
Most visible when slurping third window.
+ missing semicolons and treating targetHeight the same way in case of
un-resizable windows
`Space.layout` not accepts custom "column allocators" (per column)
An allocator allocates the available vertical space of the column.
The default column layout allocates the vertical space proportionally to the
member's existing height, but strives to preserve the height of the selected
window.
During a grab the grabWindow's geometry is never changed (as this is very
jarring for the user) and the column is laid out accordingly.
The layout triggered from grabEnd cleans things up (eg. if the grab-resize freed
up space not possible to allocate without moving the grab window)
Pending changes/cleanups:
- Rewrite `deferLayout` hack
Resolves#62
`Space.layout` can cause a resize, causes a move_to, triggering `moveDone`
_before_ all layout animations are started. The actor and clones of the windows
to the right is swapped and subsequent layout animations are broken. (animating
the hidden clone)
Observable when slurping / barfing when there's 2-3 windows visible to the
right (NB: without the navigator visible)
EDIT: This fix assume layouts affecting the selected window run `ensureViewport`
manually if necessary, but note that `Space.layout` actually ensures the
selected window (although only when animating)
The assumption that every line was timestamped turned out to be wrong [1]
causing the skip filters to break (and distort the output)
Abandon timestamp and message on separate line. Print only the time part of the
timestamp to save horizontal space.
Goto mark when the it's already focused now selects previous (mru) window.
Quite common to just quickly check a marked window - more convenient to repeat
the binding instead of using super-tab.
Tor Hedin Brønner