Bug 388353 - In View mode, with the scroll behavior set to "Browse", scrolling with the touchpad is too fast
Summary: In View mode, with the scroll behavior set to "Browse", scrolling with the to...
Status: RESOLVED FIXED
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: 17.12.2
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords: junior-jobs, usability
Depends on:
Blocks:
 
Reported: 2017-12-30 12:31 UTC by RaitaroH
Modified: 2018-04-04 09:21 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 18.04.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description RaitaroH 2017-12-30 12:31:46 UTC
I did find this bug: https://bugs.kde.org/show_bug.cgi?id=297853

For me the problem is in the "View" mode. If I even touch the touchpad I scroll 100+ images at once. I honestly cannot use the touchpad to scroll at all. The mouse wheel has no issues at all though. I can scroll one image at the time.
Also if it helps, if I scroll with the touchpad in vlc I have the same problem, the volume changes too fast.

A few images, if it helps:
Touchpad settings:
https://i.imgur.com/Wi9gNtq.png
https://i.imgur.com/2l2iXsc.png
Mouse:
https://i.imgur.com/FrVXvFC.png

In dolphin the scrolling seems fine, touchpad or mouse. Adding widgets on the other hand has a very slow scroll, regardless of input.
Comment 1 RaitaroH 2017-12-30 12:37:35 UTC
KDE Neon 5.11 64bit, KDE Plasma version 5.11.4
Comment 2 null 2017-12-30 15:01:36 UTC
Thanks for the report.

I don't have access to a touchpad right now so cannot reproduce, but at least I want to mention that beforehand you'd have to go to Gwenview's settings → Image View → Mouse wheel behaviour and select "Browse".

I suspect the touchpad is creating a lot of very small scroll increments and this needs special handling in the code compared to the "traditional" way of scrolling (could probably copied from elsewhere, e.g. the fix for Bug 378584).

(Regarding scrolling in QML based UIs like the "Add widgets" dialog: I believe this is a known problem depending on library versions and input stack. Unrelated to Gwenview, though.)

@RaitaroH: One more thing: Could you also test whether scrolling (i.e. panning after zooming in in View mode) is also too fast when selecting "Scroll" instead of "Browse" in the settings? (And possibly anywhere else?) Thanks!
Comment 3 RaitaroH 2017-12-30 16:06:35 UTC
@Henrik Fehlauer 
I already have it set to browse. It was the first change I made.
Setting it to scroll and scrolling with the touchpad in a zoomed in image seems fine too me. It doesn't scroll too fast, but it is quite smooth (good thing). The mouse is more blocky, x number of lines with every small scroll. So there isn't any problem there from what you can see.
Comment 4 RaitaroH 2018-01-01 07:45:28 UTC
Just to see if it might be something installed later on by me the cause of this problem, I have tried gwenview in KDE Neon live mode (neon-useredition-20171228-1018-amd64), but the problem is still there.
Comment 5 null 2018-01-01 07:58:29 UTC
Thanks for testing again.

> I already have it set to browse. It was the first change I made.
That's what I suspected ;) I only mentioned it in case somebody else reading the bug stumbles about this (in general it is important to note any changes from the default config when reporting a bug).

> the problem is still there
I think the next step (once someone finds the time) would be to fix the code.
Comment 6 RaitaroH 2018-01-01 08:07:27 UTC
Well, this is KDE after all, I am sure it will be fixed soon enough.
Comment 7 Nate Graham 2018-01-03 14:09:01 UTC
Can confirm with my touchpad: it scrolls through images too fast in browse mode. For me and my touchpad settings it's not "100-images-at-a-time-too-fast", but still noticeably "too fast". We will probably have to apply another fix like the one in Bug 378584, just like Henrik says.
Comment 8 RaitaroH 2018-03-03 11:23:14 UTC
I first thought this is a Gwenview issue.

I also noticed though that trying to switch desktops by scrolling with the touchpad (hover the desktop) is also very fast in imprecise.

I even noticed that Latte-Dock had the exact same problem but it got fixed:
https://github.com/psifidotos/Latte-Dock/issues/892#issuecomment-370139533

I think maybe this bug should be placed in another category and not gwenview.
Comment 9 null 2018-03-04 07:11:09 UTC
I'm not sure how a fix in Plasmashell can possibly affect Gwenview, but if you think moving it there helps resolving it faster…

In my book it's either a libinput/Qt related issue, or it has to be solved separately in every app.
Comment 10 Nate Graham 2018-03-06 12:45:43 UTC
This isn't an issue in Plasma, it's Gwenview-specific. Plasma doesn't handle scrolling in KDE apps. If you have scroll speed issues in other contexts, please file new bugs.


Another data point: RaitaroH is using Synaptics, but I can reproduce using Libinput.
Comment 11 RaitaroH 2018-03-06 17:10:03 UTC
(In reply to Nate Graham from comment #10)
> This isn't an issue in Plasma, it's Gwenview-specific. Plasma doesn't handle
> scrolling in KDE apps. If you have scroll speed issues in other contexts,
> please file new bugs.
> 
> 
> Another data point: RaitaroH is using Synaptics, but I can reproduce using
> Libinput.

If it were just a gwenview thing like I thought at first... why was:
1. latte affected (then had to be fixed)
2. switching desktops with scrolling over the empty desktop also affecred. The touchpad is too fast (actually I had no idea that was a feature before I discovered it by accident)
3. vlc is also affected when scrolling to increase or decrease the volume, which is really fast if done with the touchpad, but is ok if is with the mouse. I don't do it that much so I didn't notice.
Comment 12 Nate Graham 2018-03-06 17:47:54 UTC
The answer is that they all have issues with their scrolling implementations, and you should file a bug for each one. :)
Comment 13 RaitaroH 2018-03-06 20:10:53 UTC
(In reply to Nate Graham from comment #12)
> The answer is that they all have issues with their scrolling
> implementations, and you should file a bug for each one. :)

XD, seriously? I thing at that point it might be something that could be fixed that would fix all of them at the same time. Also this is most likely not a full list either so that means even more bugs for the same thing.
Comment 14 Nate Graham 2018-03-06 20:19:02 UTC
Yes, seriously:
- It's not a Plasma issue since Plasma doesn't affect apps' scrolling implementations
- It's not an issue with the Qt scrollview since the problem described in this bug pertains to a custom scrolling implementation
- It's not a driver issue (e.g. with synaptics or libinput) issue because it doesn't affect everything, just certain custom scrolling implementations like this one

That leaves individual apps as the culprits. It's not at all a surprise to me that scrolling with a touchpad is still a second-class citizen in Linux software. Linux (and Windows, to be fair) folks have been relatively slow to adopt laptops with touchpads as full-time work machines without plugging in external mice, probably due to historically abominable touchpad input drivers and software support.

We've already fixed Gwenview to handle touchpad scrolling more reasonably in other contexts; see for example Bug 378584.

That was a pretty small patch; would you like to have a go at producing a patch based on that for this issue?

Here's the documentation: https://community.kde.org/Get_Involved/development
Comment 15 null 2018-03-06 20:21:58 UTC
Why is it not a Qt issue? Maybe I'm mixing up things, but wasn't there a problem where a newer Qt would send a gazillion of wheel events? Did someone actually test with a really old distro with an old Qt whether the problem is also present there?
Comment 16 Nate Graham 2018-03-06 20:38:03 UTC
You may be thinking of https://bugreports.qt.io/browse/QTBUG-59261, which is not the cause for two reasons:
- It only affected the libinput driver, but RaitaroH is using the Synaptics driver
- The bug caused touchpad scrolling with libinput to be too slow, not too fast

Or maybe you're thinking of another Qt bug that I'm not as familiar with?
Comment 18 Huon 2018-03-10 01:55:14 UTC
I've implemented the zoom fix for this as well: https://phabricator.kde.org/D11200
Comment 19 Huon 2018-03-12 03:14:45 UTC
Git commit 8b11365cace8b060236837c4938668842bbe7b6a by Huon Imberger.
Committed on 12/03/2018 at 03:14.
Pushed by huoni into branch 'master'.

Fix scrolling with touchpad when in Image view and mouse wheel behaviour set to Browse

Summary:
Similar to zooming using Ctrl+touchpad two-finger scroll, using touchpad scrolling
in image view when mouse wheel behaviour is set to Browse, browsing images is way
too fast.
This implements the same fix in {D7744} for this case.

Test Plan:
  # Settings > Image View > Mouse wheel behaviour = Browse
  # Open folder with a bunch of images, switch to Image view
  # Enable thumbnail bar
  # With mouse over image, scroll with the touchpad

Reviewers: #gwenview, ngraham, rkflx

Reviewed By: #gwenview, ngraham, rkflx

Subscribers: mart

Differential Revision: https://phabricator.kde.org/D11200

M  +5    -2    lib/documentview/documentview.cpp

https://commits.kde.org/gwenview/8b11365cace8b060236837c4938668842bbe7b6a