There's a few differences in how onComplete is run:
- We need to run moveDone on every clone transition, as the transitions aren't
done when cloneContainer's transition finishes
- We cannot run layout until startup is done. For some reason onComplete runs
before monitor setup is done properly.
squash! Use clutter animations
- Can't use addTween as a timeout, but transitions are now finished when
onComplete is run, so there's no need for this anymore.
The scratch window would first be moved to the remembered position - then
animated "down".
Also ensures that windows minimized when navigating get a proper position.
(restoring a window that was minimized when it was non-placeable results in the
window being out-of-view)
Note: Use 'effect-completed' to detect when a the animation is done - then
resize/move. Could also have stored the target position, but that complicates
all the places we want to preview a minimized window.
Specifically fixes bug where whole scratch layer become visible (but only the
actors) when reloading (or disable/enable cycle) when at least on scratch window
was active.
This also sometimes crashed gnome-shell (confirmed on v3.28.3 - ubuntu 18.04)
Also remove some code who seem to partly work around the problem
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.
We're assessing all top level declarations from outside the original scope when
we're evaluating code. So everything should be `var`.
Classes are `let` bound so we should use var for `ClickOverlay` too, but there's
a bug in gnome-shell-mode making such statements not evaluate. We therefor wait
for that to be fixed.
Attaching and detaching windows could be somewhat disorienting. Eg. making the
focused window hidden by other floating windows when attaching the current
window to the tiling.
On startup we use a heuristic to figure out which windows should float in the
scratch layer, but from then on we simply check if the window is marked as
floating.
NB: Since `above` is reset when a window is minimized there's no guarantee that
a floating window will be above when visible.
This makes it possible, with some work, to use a combination of above and
minimized to detect scratch windows. Leaving always visible on all workspaces
functional for multimonitor use.
As mentioned we need to use a combination of above and minimized since minimized
windows can't be above.
(in scratch windwo MRU order of course)
Ideally the scratch layer would somehow mutate the MRU itself on
activation, but it seems the only way to do this is to actually focus
the windows in turn. That might be slowish(?) and also messes with the
stacking order (I think). Ie. would need to restore the stacking order
after doing the focus dance.
