GNOME Bugzilla – Bug 707973
appDisplay: Improve touchpad scroll on app picker
Last modified: 2020-01-13 07:45:40 UTC
Currently scroll on touchpad devices are managed like pointer devices scrolling. But since most touchpad devices are smooth scroll capables, they trigger a lot of scroll-event for each little change with the fingers. Also, interpolated events cause that the view keeps scrolling after the user raise his hand. For a discrete elements inside a scrollView like the appPicker it is annoying, since it changes pages for each little change. Also, although we guess how to solve that; it still changes pages after the user raise his hand. This patch fixes both drawbacks, first, holding the page change while the animation of the page change is ongoing, which solves the first drawback; and second, trying to avoid the events triggered after the user raise his hand, using some heuristics with a historic of the dy values of scroll and taking advantage of that the values of smooth scrolling draw a curve, and we can filter the values that are decreasing, which are the values that are triggered after the user raise his hand.
Created attachment 254782 [details] [review] appDisplay: Improve touchpad scroll on app picker Currently scroll on touchpad devices are managed like pointer devices scrolling. But since most touchpad devices are smooth scroll capables, they trigger a lot of scroll-event for each little change with the fingers. Also, interpolated events cause that the view keeps scrolling after the user raise his hand. For a discrete elements inside a scrollView like the appPicker it is annoying, since it changes pages for each little change. Also, although we guess how to solve that; it still changes pages after the user raise his hand. This patch fixes both drawbacks, first, holding the page change while the animation of the page change is ongoing, which solves the first drawback; and second, trying to avoid the events triggered after the user raise his hand, using some heuristics with a historic of the dy values of scroll and taking advantage of that the values of smooth scrolling draw a curve, and we can filter the values that are decreasing, which are the values that are triggered after the user raise his hand.
*** Bug 731197 has been marked as a duplicate of this bug. ***
*** Bug 727206 has been marked as a duplicate of this bug. ***
Review of attachment 254782 [details] [review]: This patch is a big hack if someone wonders why is it not reviewed, so I reject it to make it clear...
*** Bug 747938 has been marked as a duplicate of this bug. ***
How pagination works on MacOS with a trackpad, from: https://support.apple.com/en-gb/HT4721 """ Swipe to navigate – Web pages in Safari, documents in Preview and more, just like thumbing a page in a book. Note: If there is horizontal content to scroll, this gesture will first scrolls to the end of content and then it will move to the next page. * Magic Trackpad – A horizontal two finger swipe will show the next or previous page. Tip: Once you pass the rubber-band threshold, lift your fingers to change page. Also you can flick your fingers at the end of the swipe for momentum. """ This also applies to Launchpad (the equivalent of the application grid display in the shell).
*** Bug 758142 has been marked as a duplicate of this bug. ***
*** Bug 772017 has been marked as a duplicate of this bug. ***
Hi all, if the previous proposed patch isn't suitable, here is what I've proposed in a duplicate reporting of this bug; Proposed Solution: There are a few solutions possible for this; 1: Make scrolling proportional reliant on a user defined number of "scroll lines" - meaning, the user has to scroll their touchpad a certain amount before the page changes. 2: Scroll by icon row - this may be more intuitive to use, and also retain the current behaviour somewhat. The behaviour being that the user scrolls *one click* and the application launcher scrolls one row per scroll *click*. 3: Implement free-scrolling, basically the same behaviour as seen when using an application folder within the launcher. Options 2-3 may be much easier to implement, with option 2 possibly being the more natural behaviour a user would expect when using a mouse wheel. Option 3 may feel more natural when using a touchpad, and is how an Android device scrolls, depending on the launcher used. The ideal solution would be to have an option for page/row/free scrolling - perhaps available as a right-click context menu when right-clicking a blank spot within the launcher.
*** Bug 775936 has been marked as a duplicate of this bug. ***
I think about something that could work but should be implemented in libinput. It's like in mathematics : functions can be coutinuous or discrete. Touchpad simulates a continuous function and we would like to have a sort of steps which are not continuous but discrete. Mouse just have discrete scrolls. We have in reality two types of scroll : the continous-scroll (now implemented) and the discrete-scroll (should be implemented ?) Discrete-scroll means define steps, one step equals to one discrete-scroll. Many ways could be imagined : wait some time (0.2 sec), change of speed (decreasing then increasing), position of fingers (a minimal distance). I love the change of speed^^. But then, applications must use the discrete-scroll and not the continuous-scroll to work properly depending on the situation (for example, continuous-scroll for firefox web pages but discrete-scroll for firefox items menu). Continuous-scroll can be the default one.
*** Bug 788996 has been marked as a duplicate of this bug. ***
*** Bug 783260 has been marked as a duplicate of this bug. ***
I guess https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/605 fixes this
That hasn't landed yet. Reopen this bug? If not then I will reopen bug 783260 because that one is still happening even with the latest master code.
It has, it was split, and the relevant fixes were in https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/826. As for bug 783260, though I'd like to know what speed is not too fast. It's maximum of one page per 250ms for wheel now instead of no restriction, see ttps://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/825.
One page per wheel tick is too fast, which is what it's doing. Anyway, that should now be discussed in bug 783260 instead of here.