When dragging a window to a shared secondary monitor, moveDone is blocked by
`inGrab`. However we only want this as long as the window haven't been detached
by window-entered-monitor.
When spawning windows on a secondary monitor, and there's
workspaces-only-on-primary, we simply want to connect the necessary signals and
make sure the window is shown.
When using `workspaces-only-primary` and a scratch window is moved from a
secondary monitor to the primary gnome-shell will make the window unstuck. So we
need to make it stuck again.
If there's a new workspace between `enable` and `startup-complete` we would miss
it, leaving us in a broken state.
In particular this happens when using dynamic workspaces and having a window
spawn on startup.
The opacity hack does not work in 3.32 and less. In fact setting opacity on
`queue-redraw` can kill a windows visibility entirely for some reason. The
windowactor property are fine, but the actor still doesn't show up.
So lets just kludge this for compatibility :P
fixes#184
Finally found a reliable solution for x11.
`first-frame` happens _after_ mutter has drawn the first frame. Meaning there's
a chance of seeing one broken frame (happens reliably with eg. gnome-tweaks).
This worked before as we hid the actor, but we now set opacity instead to work
around 3.34 not allocating hidden actors. opacity is apparently reset on the
first draw, meaning we need to set opacity between `window-created` and
`first-frame`, `queue-redraw` is the obvious choice here.
Clutter's transition framework will delay painting the ease until some sort of
painting is requested or whatnat, even if duration == 0.
In particular on reload this means clones are invisible for quite a while.
Simply force positions on startup.
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.
Floating windows tend not to trigger size-changed at all. Make sure we position
the clone correctly at least once.
Might of course be better to just run allocateClone when the actor is allocated
still, but I'm not entirely sure if the frame and actor is necessarily synced at
that point.
Instead of listening on the actor's allocation signal set the clones size when
the windew is resized. This works around 3.34 not allocating hidden actors.
Seem the ordering of "focus", "window-created", "window-added" and "first-frame"
and the corresponding update of eg. global.display.focus_window and the mru list
is quite complicated and non-deterministic..
Some sampling reveals the following possible combinations on 3.28 X11:
fw = global.display.focus_window, mw = metaWindow in insertWindow (new window)
fw = mw mw = mru0 !fw fw = mru0 fw = mru1
false false false false false
false false false true false
false true false false true
false true true false false
true false false false true
true true false true false
So it's quite messy, but we can (hopefully) always rely on the currently
focused ("adult") window to be in the mru.
Note: the reason we doesn't simply use `maximize(Meta.MaximizeFlags.HORIZONTALLY`
for toggle-maximize-width is that maximized windows are unmovable [1] and (more
debatable) that maximized width should honor minimumMargin.
[1] doesn't play to well with paperwm, though we have some hacks in place for
regular maximized windwos
Ref: #157
Windows sometimes was registered (`registerWindow`) twice on startup (observed
on X11 3.28) causing all sorts of problems.
Seems like the extension sometimes is enabled/disabled twice on startup causing
the 'startup-complete' signal to be connected twice. Use the `Signals` class to
manage the signal to guard against this scenario.
I added a one-shot function to `Signals` since it's an error to disconnect an
already disconnected signal and that would happen on disable if the
'startup-complete' signal disconnected the signal itself.
assoc: d8069078f2
