With `topbar-follow-focus` set to false we still moved the topbar (to its own position).
This caused issues with dash-to-panel with panels on all monitors.
So only move the topbar to the primary monitor when `topbar-follow-focus` is toggled
off by the user.
There's still some issues with dash-to-panel and the workarea on secondary monitors,
but this makes it at least somewhat usable.
Co-authored-by: Simon Epstein <simon.epstein@67bricks.com>
Currently uninstall.sh fails if run on an installation copied or cloned
directly into the extensions directory. This change updates it to check
whether the install is link-based or direct and handle each case
appropriately. Due to the potential danger of a recursive removal, it
prompts the user for confirmation before removing direct installs.
I suspect there's more going on here, since a space should always have a
monitor, so we're probably hitting an uncommon code path. But it doesn't
hurt to guard explicitly against null monitor.
closes#273
focusMonitor now falls bact to monitor-at-point on empty workspace. But since
the move-workspace-* gnome actions is registered as PER_WINDOW the default
bindings will still usually not work. (depends on who win the binding "fight")
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)
For some reason after a successful `move_frame`, and `position-changed`,
the window is moved back to it's original position. This only happens
sporadically...
Anyway, just do the simply thing and make sure all `position-changed`
signals are correct.
NOTE: need a grab guard or something for non-clutter dnd
Tor Hedin Brønner