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
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.
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
`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
After a99c151 the we caused lots of
meta_window_make_above: assertion '!window->override_redirect' failed
warnings in the log.
Most likely best to leave such windows alone.
button-press on these buttons trigger a grab (GrabOp.FRAME_BUTTON).
Our grab handler run startAnimate which tracks the background -> the
button-press is stolen
Only happened for server-side-decorated windows (make sense that the grab is not
triggered for CSD windows)
Regression after: 5d0f037d3
Per workspace settings can be accessed through `space.settings`.
A setting's path is stored under its uuid in
`/org/gnome/shell/extensions/paperwm/workspaces/${uuid}/`. When modifying a
workspace setting the uuid will be recorded in
`org.gnome.Shell.Extensions.PaperWM.WorkspaceList`.
Spaces get their settings by looking for an uuid with an `index` key
corrosponding to its `workspace.index()`. If such a setting can't be found the
space will be given a fresh uuid and the name and color will be assigned as
before.
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 use this pattern all over the place:
```
signals = [ foo.connect('bar', handler) ];
signals.forEach(id => foo.disconnect(id));
```
So we abstract it into a class that keeps track of the state automatically.
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.
Tentative keybinding: <super>t
Probably need some more work to be useful: Almost fully hidden windows
should probably be excluded for instance. Could also utilize
minimum-width per window-class, historic window size, heuristics to
determine how many of the windows to tile.
The name could be better since we're always tiled in some sense.
"distribute", "reallocate", etc.
Might be that a `tile-neighbour`[1] is better, or that a couple more
resize commands would make it quick enough to allocate space more
manually:
- `expand-width`: increase the the width of the current window by the
amount available from partially visible windows. If/when we make
resize commands work in "super-mode" one could quickly reallocate
space without messing up the MRU list too.
- `slurp`: squeeze the fist partially visible window fully into the
view port, probably stealing at least some space from the existing
windows.
[1] need two bindings though
