Bug 297853 - Smooth scroll of thumbnails
Summary: Smooth scroll of thumbnails
Status: RESOLVED FIXED
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: 2.8.1
Platform: Archlinux Linux
: NOR wishlist with 10 votes (vote)
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords:
: 323681 434564 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-10 15:10 UTC by Majki
Modified: 2021-03-17 23:20 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 21.04


Attachments
Moves setSingleStep() call under updateGeometries(). Enables smooth scrolling (1.76 KB, patch)
2013-06-29 16:52 UTC, vadzim.miliantsei
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Majki 2012-04-10 15:10:02 UTC
I would like to have smooth scroll in thumbnails view. Currently it scrolls in half-of-the-screen steps, which makes hard to browse images. You constantly "jump too far" and have to use scrolling bar on the right to have more precise scrolling.
Comment 1 vadzim.miliantsei 2013-06-29 16:52:06 UTC
Created attachment 80854 [details]
Moves setSingleStep() call under updateGeometries(). Enables smooth scrolling
Comment 2 Holger 2013-08-19 19:26:08 UTC
*** Bug 323681 has been marked as a duplicate of this bug. ***
Comment 3 Nate Graham 2017-09-09 20:10:03 UTC
Thanks for the patch, Vadzim! Unfortunately, as you can see, it's been completely ignored for 4 years. :( Patches on bugzilla tend to get missed. If this is still an issue with KF5 versions of Gwenview, can you upload it to Phabricator, KDE's patch and code submission infrastructure? http://phabricator.kde.org/

Please let me know if the issue is already fixed or no longer relevant.

Thanks!
Comment 4 Nate Graham 2018-01-25 03:36:24 UTC
Contacted the patch submitter, no reply. And it seems that this has already been implemented as far as I can tell, based on the limited description.
Comment 5 Holger 2018-01-26 01:40:19 UTC
@Nate

Which version has this been implemented? 17.04.3 is as jumpy as ever. To get the full effect, just enlarge the thumbnails to 256x256 pixel. Only briefly touching the scroll wheel will jump 3 rows at a time, which is more than half a Full-HD monitor. This is far beyond any definition of smooth scrolling.

As a workaround, I use the keyboard, to jump only a single row at a time. This still isn't smooth, but a lot better than 3 lines.

Maybe you confused this bug with the single line preview bar under the display of the current picture? There is some kind of smooth scrolling implemented, but the thumbnail-overview is not fixed. Please reopen.
Comment 6 Patrick Silva 2018-01-28 01:17:54 UTC
scrolling seems smooth on my systems, Arch Linux (gwenview 17.12.1) and neon dev unstable.
Comment 7 Nate Graham 2018-01-28 04:11:40 UTC
In gwenview 17.12.1 and 18.03.70 (unreleased; compiled from git master), using my mouse's scroll wheel on humongous thumbnails makes them move by less than one thumbnail width/height per scroll tick.

If you continue to experience the same issue once you get any of those versions, it could be an issue with your mouse scroll settings.
Comment 8 null 2018-01-28 22:35:44 UTC
It's still an issue for me using a mouse wheel. Basically, Gwenview's Browse mode (aka thumbnail view) uses the number of lines assigned to a scroll tick in your mouse config in "systemsettings", which is 3 by default. In case you have large thumbnails or just a small window height, this can mean a single scroll can be equivalent to a PageDown press (it's capped to never skip rows, luckily).

I'm a bit unhappy in general with how jumpy scrolling works with a mouse wheel in Gwenview and also in Dolphin (it's better with a touchpad supporting pixel-perfect smooth scrolling, I guess). Items jump around too much, so I never really know where the items I was looking at are located afterwards. In Firefox, smooth scrolling, the scrolling distance and scrolling acceleration work much better (I tweaked it a bit in about:config, though), which displays both text and larger graphical elements.

I wonder if we should just hardcode the scrolling distance to 1 row (+ a small offset) or provide a config option? (Firefox-like scrolling is probably out-of-scope here.) On the other hand, scrolling should not get too slow for directories with an enormous amount of images. Maybe we could base it on a fixed percentage of the viewport height? (I did not try the attached patch yet, maybe it helps already.)

Nate: Thoughts? Please reopen if you can confirm.
Comment 9 Nate Graham 2018-01-29 00:26:00 UTC
OH! I know what the problem is. I had interpreted this bug as applying to the thumbnail *bar* instead of the thumbnail *view*. That's probably my bad. (The thumbnail bar behaves properly in this use case FWIW). I can confirm the problem now.

The issue of scrolling by row with tall rows is actually identical to the one you bring up in Dolphin, which is tracked by Bug 386379, and for which there is a potential patch: https://phabricator.kde.org/D10102. We might consider doing the same thing here.
Comment 10 Nate Graham 2018-01-29 00:26:36 UTC
...Or use/adapt the patch in this bug too, of course.
Comment 11 Nate Graham 2018-01-29 00:38:11 UTC
Actually I had misunderstood the aforementioned Dolphin patch, which makes the issue better there, but does not resolve it. It will not work here, unfortunately.
Comment 12 Nate Graham 2021-03-05 15:41:30 UTC
Git commit 9ce466f6fd6f11da344cd1ab74537e7d59e2b59c by Nate Graham, on behalf of Arjen Hiemstra.
Committed on 05/03/2021 at 15:40.
Pushed by ngraham into branch 'master'.

Base scroll speed on text height rather than image row height

Apply the same change[^1] as we did a while ago for KDirOperator and
Dolphin to effectively reduce the scroll speed when using large
thumbnails, otherwise scroll with a mouse wheel ends up being useless.

[1]:
https://invent.kde.org/frameworks/kio/-/commit/59b944470470f6bb65fc46cfff8181f7887fd9c8

M  +6    -0    lib/thumbnailview/thumbnailview.cpp

https://invent.kde.org/graphics/gwenview/commit/9ce466f6fd6f11da344cd1ab74537e7d59e2b59c
Comment 13 Nate Graham 2021-03-17 23:20:38 UTC
*** Bug 434564 has been marked as a duplicate of this bug. ***