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.
PreviewedWindowNavigator used `spaces.length` and the multimap used
`spaces.forEach` when using stable workspace order. That should be the last
usage of `spaces` as an array.
At the moment this doesn't improve things much as array indexing worked before.
And the multimap will still crash gnome-shell when going to removed workspaces.
This sets us up to use a hash map instead of an array of spaces, which is much
more robust since `workspace_index` isn't well suited as an identifier for a
workspace.
Fixes#35
Use n-workspaces signal to create/destroy new workspaces.
We're still using the workspace_index to lookup spaces. But indexes line up
since we're removing the space at index n when the workspace with index n was
removed.
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.
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.
Tor Hedin Brønner