| Summary: | Smooth scroll of thumbnails | ||
|---|---|---|---|
| Product: | [Applications] gwenview | Reporter: | Majki <skynet> |
| Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | bugseforuns, nate, nortexoid, null, private_lock |
| Priority: | NOR | ||
| Version: | 2.8.1 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/gwenview/commit/9ce466f6fd6f11da344cd1ab74537e7d59e2b59c | Version Fixed In: | 21.04 |
| Sentry Crash Report: | |||
| Attachments: | Moves setSingleStep() call under updateGeometries(). Enables smooth scrolling | ||
|
Description
Majki
2012-04-10 15:10:02 UTC
Created attachment 80854 [details]
Moves setSingleStep() call under updateGeometries(). Enables smooth scrolling
*** Bug 323681 has been marked as a duplicate of this bug. *** 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! 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. @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. scrolling seems smooth on my systems, Arch Linux (gwenview 17.12.1) and neon dev unstable. 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. 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. 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. ...Or use/adapt the patch in this bug too, of course. 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. 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 *** Bug 434564 has been marked as a duplicate of this bug. *** |