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.
Needed when the `to` window is in the scratch. In that case focus_handler
doesn't cause a moveDone.
The most obvious effect (X11) of not calling moveDone is that the background is
still tracked and the scratch window is thus unresponsive (ref: #80). It
also makes the tiled windows unresponsive to the first click since the window
actors will be hidden (wayland too I think) - the tiling will pick up the click
and activate the clicked window though.
Try to make it a bit more "action oriented":
An action exists independently of its binding. It could conceivable be invoked
by other means too.
Some weirdness from the marriage remain to weed out, but this is a working
stepping stone.
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.
Pressing <meta>-ESC will now abort workspace changes the same way window changes
are aborted
Probably fixes#37 too (untested since <super>-TAB is restricted to active workspace
atm.)
When navigating workspaces in mru order animating the workspaces based on the
mru order gives a false sense of spatiallity. Instead simply animate the
previewed workspace from the bottom and animate the last workspace down.
Functions which are called from signals is left alone for now since
`dynamic_function_ref` depends on looking up things in `window`. `debug` is
also still a global.
If we've previewed a workspace and then move onto another window in the same
workspace `_finish` will trigger a new workspace animation that we aren't
cancelling.
(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.
Gives more fine grained control as we can call complete when appropriate and
omits signaling mutter that workspace switching is finished, as we're not
responding to the `switch-workspace` signal.
