Bug 388353

KDE Neon 5.11 64bit, KDE Plasma version 5.11.4

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!

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

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.

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.

Well, this is KDE after all, I am sure it will be fixed soon enough.

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.

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.

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.

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.

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

The answer is that they all have issues with their scrolling implementations, and you should file a bug for each one. :)

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

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

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?

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?

So here are the other bugs:
https://bugs.kde.org/show_bug.cgi?id=391551
https://trac.videolan.org/vlc/ticket/19965#ticket
https://github.com/Zren/plasma-applet-eventcalendar/issues/4

I've implemented the zoom fix for this as well: https://phabricator.kde.org/D11200

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