Be more liberal with what we consider to be a wide window. Another option is
having the cutoff be `stack_margin + window_gap` which means we'll center as
long as there's no other non-scaled window on the screen.
When a window is removed the new focus is triggered before the `window-removed`
is triggered. But the actor is already gone, so we use that as a proxy.
This change should facilitate handling windows that are minimized too.
The panel can be hidden by more than ensure_viewport. There's no point in
animating on the `hide` signal, but we can position the panel correctly,
later show animations work properly and will make sure any popdowns are position
correctly too.
Should ideally have hide animation in a signal too, but this doesn't seem to be
viable as it gnome-shell tries really hard to hide the panel when focusing a
fullscreen window.
Ie. if we disconnect both signals, show the panel while animating out
gnome-shell will just hide it again.
Regression: enable() is run too early to find the topbar the way we did it
before. Commented out the statusbar.visible handling, and hardcoded the height
for now.
TODO: find a signal we can use to find the topbar properly.
When there's enough screen width to fit all windows, make them share the
available space evenly.
NOTES:
This does NOT set the currently ensuring window, and does an ugly early return.
To reproduce:
- activate the popup
- move the pointer over an entry
- use the keyboard to select another entry
On modifier release the keyboard-selected window get focus, but the mouse/pointer
hovered window is ensured.
Not sure why item-enter (hover) is triggered since the pointer already has
entered that item, but this is a workaround. Even if the pointer was required to
move the situation could probably be triggered by actually moving the pointer
while releasing the modifier key.
This should in principle start the animation when the obscuring window have
moved margin - margin_lr frames, which is in the ballbark of what we want.
Had to divide the whole thing by two, not sure why that should've been necessary.
It might be better to use easeOutQuad though, since the other windows are
already moving.
This make scaling and positioning windows with different buffer/frame deltas
consistent, and is what we actually want. ie. the height we're interested
setting is the height of the visible window (not the air around it).
Tor Hedin Brønner