Gnome Shell app list scrolls too quickly with mouse wheel

[Daniel van Vugt]

https://bugzilla.gnome.org/show_bug.cgi?id=783260

---

Gnome Shell app list scrolls too quickly with mouse wheel.

It seems to scroll one page per wheel tick, which is way too much.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: gnome-shell 3.24.2-0ubuntu4
ProcVersionSignature: Ubuntu 4.10.0-21.23-generic 4.10.11
Uname: Linux 4.10.0-21-generic x86_64
ApportVersion: 2.20.5-0ubuntu4
Architecture: amd64
Date: Tue May 30 14:08:46 2017
DisplayManager: lightdm
GsettingsChanges:
 b'org.gnome.shell' b'command-history' b"['ls', 'xterm', 'caribou', 'cariboukkk', 'cariboukkkkjj']"
 b'org.gnome.shell' b'app-picker-view' b'uint32 1'
 b'org.gnome.shell' b'favorite-apps' b"['firefox.desktop', 'chromium-browser.desktop', 'gnome-control-center.desktop', 'org.gnome.Terminal.desktop', 'rhythmbox.desktop', 'yelp.desktop', 'org.gnome.Nautilus.desktop', 'org.gnome.Software.desktop']"
 b'org.gnome.desktop.interface' b'gtk-im-module' b"'gtk-im-context-simple'"
 b'org.gnome.desktop.interface' b'scaling-factor' b'uint32 1'
InstallationDate: Installed on 2017-05-03 (27 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170502)
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

[Carlos (csoriano)]

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.

[Carlos (csoriano)]

Created attachment 254782
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.

[Florian-muellner (florian-muellner)]

*** Bug 731197 has been marked as a duplicate of this bug. ***

[Florian-muellner (florian-muellner)]

*** Bug 727206 has been marked as a duplicate of this bug. ***

[Carlos (csoriano)]

Review of attachment 254782:

This patch is a big hack if someone wonders why is it not reviewed, so I reject it to make it clear...

[Florian-muellner (florian-muellner)]

*** Bug 747938 has been marked as a duplicate of this bug. ***

[Emmanuele Bassi (ebassi)]

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).

[Florian-muellner (florian-muellner)]

*** Bug 758142 has been marked as a duplicate of this bug. ***

[Florian-muellner (florian-muellner)]

*** Bug 772017 has been marked as a duplicate of this bug. ***

[Luke (luke-nukem-jones)]

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.

[Florian-muellner (florian-muellner)]

*** Bug 775936 has been marked as a duplicate of this bug. ***

[Free-r (free-r)]

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.

[Jeremy Bícha (jbicha)]

Personally, this is much worse with a touchpad than with a mouse.

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

The GNOME term is "Activities Overview".

[Daniel van Vugt (vanvugt)]

Touchpad scrolling is covered by bug https://bugzilla.gnome.org/show_bug.cgi?id=707973
but I think that's not relevant to mouse wheels.

[Daniel van Vugt (vanvugt)]

Gnome Shell app grid scrolls too quickly with mouse wheel.

It seems to scroll one page per wheel tick, which is way too much. If you're used to using a wheel then you almost certainly have scrolled multiple pages with a single flick of the wheel.

On the other hand, waiting for multiple ticks would also be unacceptable (would feel unresponsive and cause more bug reports). So I think the only solution here is to implement proper smooth touchpad-style floating point scrolling, and let a mouse wheel tick be some proportion of that (historically 15.0f?).

[Daniel van Vugt (vanvugt)]

Using: gnome-shell 3.24.2-0ubuntu4

[Florian-muellner (florian-muellner)]

*** Bug 788996 has been marked as a duplicate of this bug. ***

[Daniel van Vugt (vanvugt)]

Almost a duplicate of bug 707973. Possibly. Not quite.

[Florian-muellner (florian-muellner)]

*** Bug 783260 has been marked as a duplicate of this bug. ***

[Florian-muellner (florian-muellner)]

*** This bug has been marked as a duplicate of bug 707973 ***

[Daniel van Vugt (vanvugt)]

Scrolling with a touchpad and mouse wheel are quite different things. The former is continuous and the latter discrete button events. But if bug 707973 improves the wheel case too then let's keep this as a duplicate.

[Daniel van Vugt (vanvugt)]

No longer tracking:

  https://bugzilla.gnome.org/show_bug.cgi?id=783260

Now tracking this instead:

  https://bugzilla.gnome.org/show_bug.cgi?id=707973

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Exalm (exalm)]

I guess https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/605 fixes this

[Daniel van Vugt (vanvugt)]

Hmm that upstream status is wrong, or linked to the wrong bug. It's definitely NOT fixed with the latest master code yet.

[Daniel van Vugt (vanvugt)]

Reopened because resolving bug 707973 did not solve this one.

[Daniel van Vugt (vanvugt)]

Moved to upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=783260

[Alexm-b (alexm-b)]

The described issue is:

> If you're used to using a wheel then you almost certainly have scrolled multiple pages with a single flick of the wheel.

This is fixed.

> On the other hand, waiting for multiple ticks would also be unacceptable

I agree.

> So I think the only solution here is to implement proper smooth touchpad-style floating point scrolling,

And this is physically impossible. You only have one event per tick, and you have no way to know when you stopped scrolling save for having a timeout, which is unacceptable as written above. :)

So doing that would lead to the page being stuck at the middle. So, any other suggestions?

[Daniel van Vugt (vanvugt)]

Yes, the page being "stuck" in the middle is more desirable. Because that way it's scrolling at the same pace as everything else in the world that responds to mouse wheels.

Perhaps the problem here is that there is a "middle". Maybe the grid should be sized such that there is no obvious gap between pages. Then it would either never need to snap, or at worst would only need to snap to the next row of icons. Not a page.

[Alexm-b (alexm-b)]

Then you're asking for a large-scale redesign. What about workspaces, which use exactly the same scrolling model and can't be made continuous?

[Daniel van Vugt (vanvugt)]

No need to focus on the solution right now. So long as the problem description is accurate then that's all I'm concerned about. That means keeping this bug open.

[Alexm-b (alexm-b)]

Ok. Anyway, paginated scrolling cannot be 100% smooth with a mouse wheel, so I'm not positive it's possible to fix this other than tweaking the timeout without breaking the whole paginated model. Anyway, switching multiple pages per flick is impossible now, so :shrug:

[Gnome-sysadmin (gnome-sysadmin)]

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.