- 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.
Creates dropdown menu to let user choose between never, always, or
only showing scratch windows. The state is tracked by two
booleans,'disable-scratch-in-overview' and 'only-scratch-in-overview'.
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.
Tor Hedin Brønner