onCompleted of the tween of the active window didn't always finish before all
other windows was done animating (seemingly at least). This caused a wrong
overlay position/width since it used `is_scaled` to find the top of the stack.
In general it's probably useful to be able to know which windows are stacked
before animations are done. Windows might be scaled for other reasons too.
Also fixes a bug where the left overlay was active even though the neighbor
fully obscured the left stack. (that caused a small region of the left most
unstacked window to unresponsive). (due to setting negative width being a noop)
Certain gnome-shell/mutter animations expect default pivot point.
Fullscreen for example looks weird with other pivot points.
It would be more correct to reset pivot point of all non-stacked
windows, but it's unlikely that eg. fullscreen animation will be
triggered on a window that hasn't been ensured since focus calls
ensure.
NB: Resetting before the tween is done causes subtle artifacts if the
window is stacked to begin with.
We have to do this since mutter/gnome-shell does not account for stacking order
when handling mouse input. Ie. the overlay region ask to receive mouse input
from mutter. It does this even when it's below a window actor. (Only affects
X11, not wayland)
Turned out to be a bit more difficult than expected to make icons
visually pleasing. Mainly during animations. Icons are thus disabled.
Problems:
- The overlay prevents the cursor from changing shape to "resize" when
hovering the left/right side of the left/right-most non-stacked
window. It still works to resize though.
- Icon support semi-broken and ugly during transitions.
Ref: #10
As a consequence the metawindows now keep track of their destination
when animated by `move_to`.
Ideally the minimap/multimap should listen for changes to the space
and react accordingly instead of doing a manual sync like this.
"most actions" means actions that is registered as PER_WINDOW and
doesn't mutate the space.
Unlikely that we'll need to specify anything else. Direct motivation
was to make it less awkward to layout after external changes trying to
integrate resize actions with "supermode".
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
This avoids situations such as when two windows are tiled, both fully
visible, but in sum a bit too wide to fulfill `minimumMargin` on both
sides. Then switching between them cause movement each time.
Could arguably be solved by setting minimumMargin to ~0 but that has
other effects too.
Note: intentionally ignored the case when _all_ windows are fully
visible. In that case we allow movement.
Note: Assumes window is on primary display
Cycle through 3 predefined window widths
Note: if we made this a mini mode, maybe 'center' could be the first
state we cycle through? Without a mode it becomes a bit annoying to
keep track of which state we're in. eg. need to remember the original
size to cycle properly.
A more robust solution would be to take the increased gap size out of the
clones' size by applying the necessary scaling. Leaving the clone
container at the same scale as the minimap viewport will then make coordinates
from the original windows translate properly.
For some reason apply_relative_transform_to_point didn't work when changing
workspace. (the _first_ workspace switch when going from only one minimap
visible to all visible)
Even when adjusting for destintationX of minimapActor.. Not really sure why, so
this isn't the most satisfying fix.
A manual transform would be needed if there's multiple actors in the ancestor
chain that is animating though. (ie. to account for destinationX instead of x)
Omitting this has no ill-effect currently, but in the selectionChrome branch[1]
it results in an empty selection when switching to a workspace out of bounds.
[1] 29d2cdfede0172ea4b420e9cae626a8c5f1bc203
Issue: Moving the window isn't actually animated in the multimap.
Note, for some reason doing an ensure on the selectedWindow makes it visible
while we preview the workspace.
Ole Jørgen Brønner