Bug 386379

All of these programs use different scroll methods, which explains the discrepancy.

Dolphin uses the KDE/Qt standard speed, which should be tweakable in the Input Devices System Settings module.

Firefox has its own scroll speed which is controlled by a hidden setting in about:config:  "mousewheel.min_line_scroll_amount"

LibreOffice likewise uses its own internal scroll speed setting and I don't think you can change it. I think there are bugs about this on their own bug tracker.

If Okular's speed is different, I think that may be worth a bug, asking it to respect the systemwide default setting like Dolphin does.

Please file bugs against those other products.

Scrolling looks the same in okular, kate and gwenview, dolphin is faster.
What do you think Nate?

Hmm, in that case maybe Dolphin is to blame here. I'll investigate. Thanks for following up.

BTW, I really appreciate your bugs. You find a lot of annoying thousand-cuts issues that are easy to fix. :) Keep 'em coming!

Think I figured out the issue, thanks to a commenter on my blog (https://pointieststick.wordpress.com/2018/01/20/this-week-in-usability-and-productivity-part-2/comment-page-1/#comment-158). Dolphin respects the global setting for number of lines to scroll per tick (which I think translates into touchpad scroll speed, too), but in icon view, each line of icons is a line, so the lines are much taller than we'd expect.

Perhaps we should normalize the height of a line before scrolling that many lines

There's a patch undergoing review that should fix this: https://phabricator.kde.org/D10102

Actually no, that patch makes it a bit better, but doesn't fix it.

Git commit 0b130dd57e594d7433141483aa162e4414a9d07b by Marco Martin.
Committed on 29/01/2018 at 10:54.
Pushed by mart into branch 'master'.

base scrolling on the smallest item

Summary:

after recent highdpi patches on scrolling that delegated it
completely to the scrollbar, based upon the scrollbar singleStep
setted to the tallest of the items in the view.
tough this makes scrolling way too fast, and on folders where just
few filenames are longer than most we can get a single scrolling
step almost double the number of lines configured in the
mouse kcm.
Using the shortest item instead of the tallest mitigates this problem
making it a bit more usable

Test Plan:
tested on different folders in different view modes both with
mouse and touchpad

Reviewers: #dolphin, broulik, ngraham

Reviewed By: #dolphin, ngraham

Subscribers: ngraham, plasma-devel

Tags: #plasma

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

M  +0    -1    src/kitemviews/kitemlistcontainer.cpp
M  +1    -1    src/kitemviews/kitemlistview.cpp
M  +8    -0    src/kitemviews/private/kitemlistsizehintresolver.cpp
M  +2    -0    src/kitemviews/private/kitemlistsizehintresolver.h

https://commits.kde.org/dolphin/0b130dd57e594d7433141483aa162e4414a9d07b

I confirm this problem is still present on plasma 5.12.0

I think the scroll should be based on the size of the text, no matter what, not on the size of the icons.
It should scroll 3 lines (or whatever number configured) of text, not 3 lines of folders.

In the same way, it seems that scrolling on the desktop switch multiple virtual desktops for the same reason.

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

@Cqoicebordel I agree 100% with you: scroll should not based on icon size that's the issue here.

Does Dolphin keep track of "rows" of items? It should scroll the rows and make sure full rows get scrolled. As it is some lose visibility between scrolls.

(In reply to whoopsdecade from comment #14)
> Does Dolphin keep track of "rows" of items? It should scroll the rows and
> make sure full rows get scrolled. As it is some lose visibility between
> scrolls.

Yes. The problem is that row height akes into account the icon size. So when icons are large, the rows are very tall. The fix is to make the row height only take into account the text size for scrolling purposes.

Unfortunately the code involved is very complex. I've tried to produce a patch that does just that, but was not successful. It's probably be up to someone with more technical skill than I.

Understand the exact problem means the solution is only one step far ... :)

What if you share some precise link to the code involved ... eventually some people here can help into find a solution.
These are my 2 cents ...

Understand the exact problem means the solution is only one step far ... :)

What if you share some precise link to the code involved ... eventually some people here can help into find a solution.
These are my 2 cents ...

Relevant files are:

src/kitemviews/private/kitemlistsizehintresolver.cpp
src/kitemviews/kitemlistview.cpp

Plasma 5.13.5

I have confirmed this bug as well in Dolphin 18.08.1. All other programs scroll correctly, and Dolphin scrolls correctly in details view; however in icons view with large icons it scrolls about 3 rows per mouse wheel click/movement, which is un-usable for my workflow with pictures. I suggest that each mouse wheel movement should scroll 1 row in icons view.

Video screenshot demonstration: https://streamable.com/3u2xd

(In reply to kdedroid from comment #19)
> I suggest that each mouse wheel movement should scroll 1 row in icons view.

That would still result in the scroll speed being too fast for people with huge icons. It might be slower, but it would still be too fast.

We need a "row" for scrolling purposes to be considered just the text and not take into account the icon size.

(In reply to Nate Graham from comment #20)
> (In reply to kdedroid from comment #19)
> > I suggest that each mouse wheel movement should scroll 1 row in icons view.
> 
> That would still result in the scroll speed being too fast for people with
> huge icons. It might be slower, but it would still be too fast.
> 
> We need a "row" for scrolling purposes to be considered just the text and
> not take into account the icon size.

That sounds great. Is there someone with knowledge of how to write this fix? This bug has been discussed for a while I see, but without a resolution. I would contribute if I had the knowledge, but am not a coder.

Clearly not, or else one of them would have done it. :)

I've taken a crack at it myself, but couldn't manage it. See previous comments for details.

This "bug" is the result of developers removing settings from Mouse Settings. It's unfortunate the settings were removed before a fully developed replacement was ready. Until this bug is fully fixed, here is my screencast of a good work-around: https://streamable.com/1vrrb

In short: Revert to the older Mouse settings dialog in order to access all the mouse setting variables. 

Hopefully this information may help others to figure out a permanent fix.

Even with the old mouse settings, reducing the number of lines per scroll tick to 1 doesn't actually solve the problem here (it just makes it less bad), but it makes scrolling three times slower for everything else.

The solution to this bug is to fix this bug. If I could, I would. If anyone else can, I'd welcome a patch!

Good point. I see that some programs are affected by this setting, and others are not. Fortunately Firefox, Thunderbird, and Libreoffice apps are UNAFFECTED by changing "3 lines" to "1 line".

Apps such as Dolphin, PCManFM-QT, QtFM, Gwenview, Kate, Okular, MasterPDF Editor, and probably other strictly Qt apps ARE affected by the change.

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

@Patrick, thank you for marking my bug as duplicate of this. I couldn't find it.

As for the bug itself, i had spend quite the large part of yesterday trying to understand what's going on with the scrolling in Dolphin and why it just doesn't feel smooth.

First off, i don't think the 3-line-scroll is bad. Not even with big icons. It's just "how" the scrolling is done (it seems to "jump" with no animation or a very VERY short animation) which makes it look bad and makes you lose focus of where you are. I too find myself often grabbing the slider to scroll these days as scrolling with the mousewheel is just not a pleasant experience anymore.

I don't fully understand it yet, but i have some findings that might be of interest.

1. Dolphin does in fact animate the scrolling with whatever the style's value for QStyle::SH_Widget_Animation_Duration is. See: https://cgit.kde.org/dolphin.git/tree/src/kitemviews/private/kitemlistsmoothscroller.cpp#n37 That on it's own is doubtful as scrolling is most certainly something else compared to fading in or hover effect animations. I don't think that value should be used for scrolling.

2. In the same file (here to be exact: https://cgit.kde.org/dolphin.git/tree/src/kitemviews/private/kitemlistsmoothscroller.cpp#n127) you can see that Dolphin uses the QEasingCurve::InOutQuad for a scroll animation and QEasingCurve::OutQuad for when you scroll _during_ an already running animation. The InOutQuad is likely causing some troubles as the duration is short, it starts of slow, then moves fast and ends slow. This can feel a bit jumpy with too short animations. Perhaps experiment with other curves if the animation time is kept as is.

3. The scrolling animation time itself. I'd say that the current animation is absurdly short. It's only sane in details view with small icons. I would advice to reconsider the animation logic and perhaps set it at 300ms.

4. Another cause for concern is re-layouting (code: https://cgit.kde.org/dolphin.git/tree/src/kitemviews/kitemlistview.cpp#n1650). If i understand the workings of the scrollview implementation correctly (it's a custom-made one on top of QGraphics*) then re-layouting is a fact we can't get around. You basically have a width x height view that is as large as your current viewport. Meaning that the viewport does not change when you scroll. Rather, the items within that viewport get a new X and Y position for every animation tick hence every animation tick needs a re-layout to make items visible and at the correct position while scrolling. It's a smart mechanism! But also really sensitive to changes. Now you know a bit about the re-layouting which makes explaining a bug i encountered in it a bit more easier to explain. When you scroll (and set the animation to something long) you can observe the items that are being scrolled to seemingly move back a pixel then jump forward two pixels at least ince during the animation. That is a bug in the re-layouting (i think). It could be as simple as an int rounding thingy where it should be a float, but it could also be as complex as just missing the animation frame. I'm assuming this alone causes a slightly jaggy scroll movement. Still it's extremely minor and you literally have to hug the screen at millimeters distance to notice it (and change the code to have longer animations) but it's there. This would explain a "it animates and looks smooth but doesn't feel smooth" experience.

5. Also for the re-layouting. It can use improvements to be as lightweight as possible. Right now it tries to show new items on every animation tick, that can be optimized to only do that if the next frame is going to show an item that isn't visible already. Also, the re-layouting runs on the GUI thread. You want to keep it as minimal and efficient as possible. Most notably, https://cgit.kde.org/dolphin.git/tree/src/kitemviews/kitemlistview.cpp#n1691 is (when you go into the recycleInvisibleItems function) looping through _all_ items on every animation tick to only determine if it can re-use items. Just to figure out that in - say - 80% (just a guess, depends on the animation and scroll speed) of the time it didn't need to know at all.

That's as far as i went this time.

What would be valuable to know is if we're making each animation frame in time. For instance, we could lose a frame (which causes jaggyness) if the above mentioned re-layouting is too expensive. Which i think it is in LARGE folders (say 100.000+).

(In reply to Mark from comment #27)

The issue here is not the animation. The issue is that a row of icons is considered a "line" to scroll. So, three rows of icons are equivalent to a tick of the scroll wheel. Which means that in a standard windowed Dolphin window, a tick of the scroll wheel means a scroll of a whole "page", of everything we can see. In fact, it goes even faster than PgUp/PgDown, which should never happen, obviously.

The solution would be to link the size of the scroll to the size of the _text_, meaning that a tick of scroll wheel should scroll three lines of _text_, whatever the size of the icons are.
PgUp/PgDown still would work for scrolling a whole page, and scrolling over the scrollbar too.

That's the issue of this bug.

I don't see the issue in Plasma 5.14.5 anymore. It seems the scroll height is ~half of what it was before, which, at least for me, is good enough.
But no idea if the issue is still there in another form or not.

Plasma and Dolphin are not related, so there's no chance that a Plasma change could affect scroll speed in Dolphin. It's possible that your distro changes some other hings around on upgrade. For example that might ship Libinput now as the input driver. But this bug is still a bug. :)

Ok then :)
(FYI, in case that would help, I just updated from Kubuntu 18.04 to 18.10, and that created the change I saw)

I'm also encountering this issue. I want to scroll half a row, but currently 1 mouse wheel scroll scrolls 2 rows of icons and there's no way to change it.

Forgot to mention, using Dolphin 18.12.1 on ArchLinux with libinput

KDE Frameworks 5.54.0
Qt 5.12.0 (built against 5.12.0)
The xcb windowing system

Observing this issue @ Manjaro Linux with
Dolphin 18.12.1
KDE Frameworks 5.54.0
Qt 5.12.0
libinput 1.12.5-1

Ok, I've been reading the code pointed to in comment 18, and started to go off on some weird tangents... And overall I'm not convinced that the actual bug is in any of that code.

Instead, I started tracking what code calls THAT code, and I found this:

https://lxr.kde.org/source/kde/applications/dolphin/src/kitemviews/kitemlistcontainer.cpp#0264

I'm fairly sure that this is where the decision is made to scroll by the height of an item, and as a result this is the code we need to look toward changing to fix this bug.

I've honestly got no clue what to use instead of the item height (I don't know whether it's appropriate to query the currently used Qt style, some KDE setting, or try to access some other member of view), but it appears this is where we need to actually be looking.

Really happy I found that. This has been the most annoying bug in KDE for me for quite some time.

Yep, that'll do it. Nice find!

I think the height of a single line of text might make sense. If that's not fast enough by default, we could do two or three. I'll experiment.

I think that there is a setting for the amount of lines scrolled
https://i.imgur.com/CHmX5ms.png

Cqoicebordel, the problem is that in Dolphin it doesn't go by lines of text, it counts the number of icons. So in most applications, having that option set to '3' will cause scrolling by 3 lines of text... But in Dolphin it scrolls by the height of 3 icons - and that includes the text under the icon, so folders with long names cause one tick of the scroll wheel to fly the view more than a screen's worth of icons downward/upward at a time.

The patch mentioned earlier in this thread makes it so that it uses the height of the shortest icon to determine scroll height, but that doesn't help if you have a folder full of things that are similarly long. And even if all icons have short, one-line names you still end up scrolling by waay more than 3 lines of text worth.

I understood that.

I was just referencing the comment of Nate Graham 
> I think the height of a single line of text might make sense. If that's not fast enough by default, we could do two or three. I'll experiment.

and wanted to point out that doing it hardcoded, by the height of a single line wasn't needed, as the setting I mentioned gives the users the choice of number of lines of text to scroll.

Ah, durp... I see what you mean now. Yeah, though I think Nate was talking about the size of the 'base' step that's considered 1 'line'.

If I knew what the preferred way of querying the line height of the text is, I'd try writing the patch myself. As it is, however, I'm not quite that confident I'd write it in a satisfactory way; I feel like I'd I'd start jumping through hoops and unnecessarily complicating the code simply due to unfamiliarity with what's available in which parts of the API.

(In reply to Cqoicebordel from comment #39)
> I understood that.
> 
> I was just referencing the comment of Nate Graham 
> > I think the height of a single line of text might make sense. If that's not fast enough by default, we could do two or three. I'll experiment.
> 
> and wanted to point out that doing it hardcoded, by the height of a single
> line wasn't needed, as the setting I mentioned gives the users the choice of
> number of lines of text to scroll.


That's not possible if you use libinput, see bug #403842

(In reply to Nate Graham from comment #36)
> I think the height of a single line of text might make sense. If that's not
> fast enough by default, we could do two or three. I'll experiment.

I don't think that's good approach. I've now been thinking about this and I think scroll speed shouldn't be related to item size at all. For example even in details view where each item is a line of text I want smooth scrolling and don't want to scroll by whole row because I might have 72 font which would make that as a huge jump too. Scrolling should be in device independent pixels (so taking into account DPI) and it should be user controllable setting (https://bugreports.qt.io/browse/QTBUG-73467) 


Also by the way, Dolphin isn't only application which does it wrong, this issue is also present in File dialog.

Relevant API:
* https://doc.qt.io/qt-5/qabstractitemview.html#verticalScrollMode-prop
* https://doc.qt.io/qt-5/qabstractslider.html#singleStep-prop

It looks like if we don't set singleStep then Qt default will be used based on verticalScrollMode.
So I think it always should be ScrollPerPixel with a good default scroll speed.

Also might consider that it could be based on window's size. For example if I have huge window I can scroll faster because there's so much space so that I'll still see all items but if window's is very small then I might want to scroll a lot slower so items don't move out of window too quickly.

(In reply to Dāvis from comment #41)
> That's not possible if you use libinput, see bug #403842

Indeed, but is the bug present when using libinput ?
For me, the bug went away when upgrading to Kubuntu 18.10, which uses libinput by default, I believe.

So if it's only an evdev bug, that setting would be present ;)

(In reply to Cqoicebordel from comment #42)
> (In reply to Dāvis from comment #41)
> > That's not possible if you use libinput, see bug #403842
> 
> Indeed, but is the bug present when using libinput ?
> For me, the bug went away when upgrading to Kubuntu 18.10, which uses
> libinput by default, I believe.
> 
> So if it's only an evdev bug, that setting would be present ;)

It is present even with libinput, you can test it yourself and you'll see that it's still there. In Dolphin set icon view, then zoom in to get biggest icon size possible and then do one tick of scroll wheel and see how much it scrolled.

(In reply to Dāvis from comment #43)
> (In reply to Cqoicebordel from comment #42)
> > (In reply to Dāvis from comment #41)
> > > That's not possible if you use libinput, see bug #403842
> > 
> > Indeed, but is the bug present when using libinput ?
> > For me, the bug went away when upgrading to Kubuntu 18.10, which uses
> > libinput by default, I believe.
> > 
> > So if it's only an evdev bug, that setting would be present ;)
> 
> It is present even with libinput, you can test it yourself and you'll see
> that it's still there. In Dolphin set icon view, then zoom in to get biggest
> icon size possible and then do one tick of scroll wheel and see how much it
> scrolled.

You are right :)

(In reply to Dāvis from comment #41)
> (In reply to Nate Graham from comment #36)
> > I think the height of a single line of text might make sense. If that's not
> > fast enough by default, we could do two or three. I'll experiment.
> 
> I don't think that's good approach. I've now been thinking about this and I
> think scroll speed shouldn't be related to item size at all. For example
> even in details view where each item is a line of text I want smooth
> scrolling and don't want to scroll by whole row because I might have 72 font
> which would make that as a huge jump too. Scrolling should be in device
> independent pixels (so taking into account DPI) and it should be user
> controllable setting (https://bugreports.qt.io/browse/QTBUG-73467) 

I'm not completely sure, but it seems like re-examining how KDE applications as a whole calculate scrolling speeds is outside the scope of this specific bug.

(In reply to Dāvis from comment #41)
> Also by the way, Dolphin isn't only application which does it wrong, this
> issue is also present in File dialog.

I'm fairly sure that the File dialog, as well as most icon views in other applications (such as Gwenview), just use the code that's within Dolphin. Gwenview's icon browsing mode is also affected, though it seems to scroll in equal increments so that after scrolling the 'new' icons' positions' are the same as the 'old' icons'.. So I'm not entirely sure it's using Dolphin's code.

(In reply to Dāvis from comment #41)
> Relevant API:
> * https://doc.qt.io/qt-5/qabstractitemview.html#verticalScrollMode-prop
> * https://doc.qt.io/qt-5/qabstractslider.html#singleStep-prop
> 
> It looks like if we don't set singleStep then Qt default will be used based
> on verticalScrollMode.
> So I think it always should be ScrollPerPixel with a good default scroll
> speed.

I'm wondering if it's worth using Qt's defaults or not. I don't know how fast/slow those would be, and I don't have Dolphin's nor KDE's source code downloaded to tinker with.. Though now that I think about it, I probably should go do that real quick to play around with it.

(In reply to Dāvis from comment #41)
> Also might consider that it could be based on window's size. For example if
> I have huge window I can scroll faster because there's so much space so that
> I'll still see all items but if window's is very small then I might want to
> scroll a lot slower so items don't move out of window too quickly.

I would personally hate for it to be based on window size. The whole reason why this bug causes issues for me is because it makes the scroll speed be different for different folders, thus causing the scroll speed to become inconsistent and unpredictable.

In my opinion, the more predictable the scrolling is the better - which means use as few variables as possible. I think that optimally it would only use user-configurable variables (such as font size, DPI, and 'number of lines to scroll'), particularly ones that you set numerically and don't expect to change without you explicitly changing them to another specific number.

I am experiencing this scrolling/paging issue in KDE Neon 5.15, Dolphin v18.12.2 using Icons View Mode and Icon size 128px. My laptop is Dell Inspiron 7537 with ClickPad-style Touchpad. 
I have discovered that Settings > Touchpad scroll does not change the behaviour in Dolphin. Only changing the Settings > Mouse > Mouse wheel scrolls by: to 1 Line has any effect. Setting this to '1 Line' makes scrolling icons in Dolphin usable.

Just wanted to confirm this issue and that only Mouse settings changes will have any effect when I'm using the touchpad. I do not use an external mouse, only the touchpad.

I've submitted a patch that fixes this: https://phabricator.kde.org/D19190

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

Git commit 403de19d9c036dd28481d3b62bdb0f49f0792fbf by Nate Graham.
Committed on 21/12/2019 at 18:54.
Pushed by ngraham into branch 'release/19.12'.

Improve scroll wheel speed by basing it on label height, not icon height

Summary:
Dolphin currently scrolls by the height of three items at a time per "step" when
using a scroll wheel. Because item height is highly variable, this leads to scroll
speed being inconsistent between views, and generally far too fast when using
icon view with icons larger than 22px size.

This patch makes the size of the scroll step based on the text label rather than the
icon size just like D25683, ensuring that the scroll speed does not vary and become
super fast when using large icons in particular.

It also reverts 90beb4a5e37b887caad1e767046a42dad0af1ab3, which is no longer needed.
FIXED-IN: 19.12.1

Test Plan:
Use a mouse with a scroll wheel and scroll in Dolphin item views with list view,
details view, icon view, etc, using different item sizes. Speed should be
consistent in all views now, and also feel consistent with other KDE apps.

Also try with multiple scale factors to make sure the behavior does not change.

No change with high-resolution two-finger touchpad scrolling.

Reviewers: #dolphin, elvisangelaccio

Reviewed By: #dolphin, elvisangelaccio

Subscribers: ahiemstra, lots0logs, anthonyfieroni, kfm-devel

Tags: #dolphin

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

M  +9    -1    src/kitemviews/kitemlistcontainer.cpp
M  +0    -5    src/kitemviews/kitemlistview.cpp
M  +0    -5    src/kitemviews/kitemlistview.h
M  +0    -14   src/kitemviews/private/kitemlistsizehintresolver.cpp

https://commits.kde.org/dolphin/403de19d9c036dd28481d3b62bdb0f49f0792fbf

Alas it seems like the proposed fix creates the opposite problem: scrolling is now way too slow for Dolphin to be usable using a mouse. Going from one line of icons to the next requires 6 "clicks" of the mouse wheel, which I deem way too much for any practical application: scrolling 10 lines of icons requires 60 "clicks" of the mouse wheel, and 10 lines are not that much!
This new patch, combined with the loss of settings for mouse and touchpads due to the move to libinput, make using Dolphin a complete pain now. I suggest finding a new solution to this issue, because the current one appears to break the user experience in a major way.

We just implemented the standard line-of-text-based scroll behavior for Dolphin, making it consistent with everything else. The fact that scrolling long distances with a mouse wheel is a pain in the neck is well known, and it's why hardware makers have made mice with free-spinning wheels and Apple implemented accelerating scrolling when turning a mouse wheel quickly.

In other words, this problem is not specific to Dolphin and needs to be fixed at a lower level. Personally I favor adding a scroll speed setting to Libinput and implementing acceleration for very fast wheel movements.

Those requests would need to be made in the Libinput project of course.

(In reply to Nate Graham from comment #51)
> We just implemented the standard line-of-text-based scroll behavior for
> Dolphin, making it consistent with everything else. The fact that scrolling
> long distances with a mouse wheel is a pain in the neck is well known, and
> it's why hardware makers have made mice with free-spinning wheels and Apple
> implemented accelerating scrolling when turning a mouse wheel quickly.
> 
> In other words, this problem is not specific to Dolphin and needs to be
> fixed at a lower level. Personally I favor adding a scroll speed setting to
> Libinput and implementing acceleration for very fast wheel movements.
> 
> Those requests would need to be made in the Libinput project of course.

If you would have read some earlier comments from here, you would find https://bugreports.qt.io/browse/QTBUG-73467 and https://gitlab.freedesktop.org/libinput/libinput/issues/185 where libinput is against implementing it and suggests it should be done in toolkits.

(In reply to Nate Graham from comment #51)
> We just implemented the standard line-of-text-based scroll behavior for
> Dolphin, making it consistent with everything else.

Nate, I understand this reason and I approve it. But let me give you another perspective: what is consistency? We can define it in two ways:
1. the actual same behaviour applied to everything, independent of the usage or the specific requirements;
2. the same perceived behaviour, which is however different in terms of how it's implemented.
The first is technical consistency, the second is UX/behaviour consistency. Scrolling text is different than scrolling a list of icons, especially when the latter can be made of especially large icons which take up the space of several lines of text. It's easy to see that the behaviour which may be entirely fine when scrolling text can not be entirely fine when scrolling icons in a file manager.
I think that in this case what is important is the UX, not the technical consistency, especially since there is no easy way to change this annoying behaviour.
I'll make a specific case for the current behaviour not to be the default. Imagine you come from Windows (and we know there are lots of people migrating from Windows 7 right now!), where scrolling is not like that of current Dolphin. You realise how tedious it is to do an easy and basic thing such as scrolling through the files in a folder. I, as a user, would immediately flee the platform and go after something else, because the alternative would be to fiddle with non-trivial stuff such as removing libinput in favour of evdev (though that could break other stuff!) or fiddling with the xorg.conf file (which is not something I would want a newbie to do as their welcome to the KDE world!).

> In other words, this problem is not specific to Dolphin and needs to be
> fixed at a lower level. Personally I favor adding a scroll speed setting to
> Libinput and implementing acceleration for very fast wheel movements.
> 
> Those requests would need to be made in the Libinput project of course.

I understand that. But what if Libinput never offers scroll speed settings, or does so in two years? Are we going to keep Dolphin with a broken behaviour just because Libinput is "broken" (from this specific usability perspective)?
My point is: wouldn't this proposed "fix" be better suited for when we have the actual correct implementation of Libinput (or whatever is needed at a lower level) available? At the moment we have two broken things, Dolphin and the mouse settings using Libinput, instead of just one, the mouse settings using Libinput.
Would it be possible to work on a different solution, at least until we have working Libinput?

I just wanted to add my point of view to the discussion that's going on:

I thought the previous behavior that scrolled more than the whole page if the icons where large enough on a single scroll wheel click absolutely maddening and completely unpredictable and bad UX and I'm very glad this has finally been fixed to be a consistent scroll speed with other applications.

I understand the frustration here. However please understand how frustrated people were with the previous behavior! :) Before the fix for this bug report, Dolphin did take into account the icon size when scrolling with a wheel and enough people hated it that we got four bug reports.

So we have a few options here:
1. Revert the fix and make everyone unhappy who thought the scroll speed with large icons was too fast
2. Bring back the old code to speed up scrolling based on icon size, but tweak the algorithm to make the scrolling speed a bit slower than it used to be, or scale it up less quickly than the icon size increases, or something else
3. Make it configurable
4. Give up and say that it's the responsibility of the toolkit or input driver


Let's go through the options:

#1 makes people unhappy enough to file lots of bug reports. Clearly a no-go.

#2 is possible, but suffers from a common problem when you try to make two groups of people happy who want opposite things: often you wind up pleasing neither group. However maybe it is possible with enough tweaking.

#3 is possible, but we generally don't like to add options like this to apps unless it's absolutely necessary, because most people never touch the settings and will be frustrated anyway, and every user-facing setting you add to a config window makes the window a little big more visually overwhelming and people already complain that KDE software's configurability is excessive and intimidating.

#4 is arguably the correct fix since Dolphin is not the only app to suffer from this issue. For example scrolling long documents in any text editor or word processor app is agonizing for the same reason, because each tick of the scroll wheel goes exactly three lines. However making it the toolkit or input driver's responsibility means no fix for the foreseeable future until developers figure out how to implement the real fix at a lower level.

As you can see, there is no obviously perfect option. Options that stand out to me are #2 and #4. I personally think that the correct solution is to make the wheel scroll speed configurable globally, not just here in Dolphin. However I'm open to #2 if anyone has any ideas--preferably in patch form. :) The code change to do this was not particularly complicated and the former code that scaled the scroll speed with large icons was reasonably comprehensible.

The previous code did:

singleStep = view->itemSizeHint().height();

Maybe we could try with:

const QFontMetrics metrics(font());
singleStep = metrics.height() * QApplication::wheelScrollLines();
singleStep = max(view->itemSizeHint().height() / 2, metrics.height() * QApplication::wheelScrollLines());

This would keep the previous scaling behavior, but make the scaling only half as big as it was before, and keep the minimum number of lines to scroll feature.

Feel free to submit patches

I don't know if I should file another report, but I'm having this bug again in 20.04.3 (and possibly earlier versions). I'm using KDE Neon. Hopefully some weird configuration issue?

It seems that the new issue is different; it doesn't depend on icon size, it's just a huge distance scrolled each tick no matter what view I use, and no matter how the items are sized.

I can't find where to change the number of lines scrolled either, it seems that option was removed. Even using evdev instead of libinput for mouse handling doesn't let me use the other options page in System Settings. I tried accessing it by commenting out the top of /etc/X11/xorg.conf.d/40-libinput.conf (which I have as a symlink to /usr/share/X11/xorg.conf.d/40-libinput.conf), which indeed loads the evdev driver for mice, but maybe KDE requires libinput to be completely uninstalled?

I'll file a new bug report, I suppose.. Not entirely sure what to include in it though, as this sounds like a few things that might be bugs but might not be.

Indeed, with libinput and Dolphin (up to and including 20.12.2) even line-based views like "Details" scroll more than a full page for every tick of the mouse wheel, incredibly frustrating. This does not appear to be consistent across QT applications, with Dolphin being the only culprit that I encounter. Punting this to libinput is not an answer, I don't think.

I am having this problem too. A minimum scroll move more than a page. This only happens in dolphin (v 20.12.2, debian). Should we reopen this bug or it is better to report a new one?