Needed to ensure all windows belong to the space's workspace. Especially this
case:
- Start navigating (from A) to the previous workspace (B).
- Drag and drop a window (X) from B to A
- Navigate back to A and end navigation.
X still belongs to B unless the full event handler run.
ref commit: Ensure all windows in the space belong to the workspace before completing workspace switch
- Activate destination workspace if it isn't active, fake it if not.
If a «stuck» window have focus, consider it selected.
If selected window or one its transient window has focus, fake focus
handler. Otherwise activate it.
- delay workspace change until DnD end (partial Navigator destroy)
- sync scratch window frame with clone on grab end
Bug in the wip commit fixed: (focus was not always preserved on workspace dnd)
- DnD a window
- switch to a different workspace using the workspace carousel
- drop the window
-> the DnD-window loose focus on workspace change (in step 2)
Note: Mutter enforce focus_window.workspace === active_workspace, changing focus
window if necessary.
This simplifies code moving windows between workspaces without messing with the
focus. (since mutter enforce focus_window.workspace == active_workspace)
Mainly preparation for DnD fixes in the next commit.
Some windows apparently report the wrong frame.y value when they've just
been maximized, leaving us with the old incorrect value. Simply hardcode
the correct y value instead.
When unlocking the desktop with a fullscreen window focused we'd incorrectly
show the topbar.
Run fixTopBar after all spaces have been fully setup to fix it.
If there's already a fullscreen window in the workspace, gnome-shell
won't trigger a hide on the topbar. Meaning fixTopBar won't run
automatically, so we need to run on any fullscreen changes.
- Simply move the fullscreen clone if not visible
- Do not start a new animation one is already in progress
- Do not run animateDown when starting navigation
It looks like mutter doesn't maintain override_redirect on wayland windows (ie.
it doesn't try to emulate the X11-only(?) concept)
This caused many menues (eg. gtk menues) to be registered by us (creating clone,
registering resize signals, etc.)
Particularily noticable in libreoffice - the menus was very delayed and
sometimes didn't show up at all. (Observed in GS 3.34.3, libreoffice 6.2.6.2)
(TOOLTIP is checked preemptively)
Ole Jørgen Brønner