Closes#371
Right now when I three-finger scroll in Wayland, moving my hand to the
right makes the windows move to the right as if dragging the proverbial
paper. As in, scrolling moves the content, not the view. In Gnome's
mouse/trackpad settings, this is referred to as "Natural Scrolling". One
can disable "Natural Scrolling" such that two-finger scrolling results
in moving the view, not the content.
This commit makes PaperWM respect the natural-scroll touchpad global
setting. If unnatural scrolling is enabled in Gnome's global settings,
then PaperWM will use unnatural scroll touchpad gestures, and vice versa.
The scroll direction is encoded as either a 1 or -1 and checks the Gnome
settings every Clutter.TouchpadGesturePhase.BEGIN.
There could be an extension added to this to make this setting
toggle-able separately from Gnome's global settings. There could be a
separate setting that overrides the Gnome global setting. There could be
people who prefer unnatural scrolling for their browser and such but
natural scrolling for PaperWM.
If the focused window is not stacked, it stacks it at the bottom of an adjacent column
If the focused window is stacked, it moves it out into its own column.
Co-authored-by: Michael Root <michael.root@rjginc.com>
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.
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)
