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.
Selecting the window under the pointer doesn't work very well when
gliding.
Simply ignore it for now, letting us always listen on the background in
wayland.
Not the prettiest code, but it works fairly well.
Selecting the target window works like this (when gliding is finished):
- if the tiling is outside the monitor select the first/last window and snap
- if there's any fully visible windows select the closest one
- if there's no visible window choose the window with highest visible width ratio
This is all calculated the moment we release the swipe, so instead of showing
any potential overshoot we simply adjust the travel so it doesn't overshoot.
There's a few differences in how onComplete is run:
- We need to run moveDone on every clone transition, as the transitions aren't
done when cloneContainer's transition finishes
- We cannot run layout until startup is done. For some reason onComplete runs
before monitor setup is done properly.
squash! Use clutter animations
- Can't use addTween as a timeout, but transitions are now finished when
onComplete is run, so there's no need for this anymore.
If the selected window is still visible we don't forc alignment with the monitor
edges, making it possible to eg. center the first/last window with a touchpad.
In the case of overshooting the last/first window we could end up not having a
window under the pointer, resulting in going back to the starting window.
The code indicates that the intention was always to ensure at the end :/
The code isn't all that pretty, but it's easy to modify and tune to test what
works well.
I've opted to keep the workspace menu's smooth scroll implementation. When
swiping it's necessary to wait for a button press on the desired space since the
pointer can be anywhere. As such making sure that the workspace stack always
ends up in a discrete state isn't that useful, so I opted for more control when
swiping.
We should add some preferences that users can use to tune the speed of swiping.
I assume that this can vary quite a lot between different touchpads.
