[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Facundo Aguilera]

https://bugs.kde.org/show_bug.cgi?id=386379

Facundo Aguilera  changed:

   What|Removed |Added

 CC||budin...@gmail.com

--- Comment #59 from Facundo Aguilera  ---
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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[pdf]

https://bugs.kde.org/show_bug.cgi?id=386379

pdf  changed:

   What|Removed |Added

 CC||k...@obfusc8.org

--- Comment #58 from pdf  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Colin Griffith]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #57 from Colin Griffith  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Colin Griffith]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #56 from Colin Griffith  ---
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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #55 from Nate Graham  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Thomas Käfer]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #54 from Thomas Käfer  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Riccardo Robecchi]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #53 from Riccardo Robecchi  ---
(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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Dāvis]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #52 from Dāvis  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #51 from Nate Graham  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Riccardo Robecchi]

https://bugs.kde.org/show_bug.cgi?id=386379

Riccardo Robecchi  changed:

   What|Removed |Added

 CC||sephiroth...@hotmail.it

--- Comment #50 from Riccardo Robecchi  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

Nate Graham  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED
  Latest Commit||https://commits.kde.org/dol
   ||phin/403de19d9c036dd28481d3
   ||b62bdb0f49f0792fbf
   Version Fixed In||19.12.1

--- Comment #49 from Nate Graham  ---
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-1src/kitemviews/kitemlistcontainer.cpp
M  +0-5src/kitemviews/kitemlistview.cpp
M  +0-5src/kitemviews/kitemlistview.h
M  +0-14   src/kitemviews/private/kitemlistsizehintresolver.cpp

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

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Postix]

https://bugs.kde.org/show_bug.cgi?id=386379

Postix  changed:

   What|Removed |Added

 CC||pos...@posteo.eu

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Patrick Silva]

https://bugs.kde.org/show_bug.cgi?id=386379

Patrick Silva  changed:

   What|Removed |Added

Version|19.04.2 |19.11.80

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[MarcP]

https://bugs.kde.org/show_bug.cgi?id=386379

MarcP  changed:

   What|Removed |Added

 CC||iwannaber...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Patrick Silva]

https://bugs.kde.org/show_bug.cgi?id=386379

Patrick Silva  changed:

   What|Removed |Added

 CC||manuelcha...@gmail.com

--- Comment #48 from Patrick Silva  ---
*** Bug 410440 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Patrick Silva]

https://bugs.kde.org/show_bug.cgi?id=386379

Patrick Silva  changed:

   What|Removed |Added

Version|19.04.0 |19.04.2

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Patrick Silva]

https://bugs.kde.org/show_bug.cgi?id=386379

Patrick Silva  changed:

   What|Removed |Added

Version|18.12.1 |19.04.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Ville Aakko]

https://bugs.kde.org/show_bug.cgi?id=386379

Ville Aakko  changed:

   What|Removed |Added

 CC||ville.aa...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #47 from Nate Graham  ---
I've submitted a patch that fixes this: https://phabricator.kde.org/D19190

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[norton]

https://bugs.kde.org/show_bug.cgi?id=386379

norton  changed:

   What|Removed |Added

 CC||norton.mil...@gmail.com

--- Comment #46 from norton  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[whoopsdecade]

https://bugs.kde.org/show_bug.cgi?id=386379

whoopsdecade  changed:

   What|Removed |Added

 CC|jcdop...@gmail.com  |

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Colin Griffith]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #45 from Colin Griffith  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #44 from Cqoicebordel  ---
(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 :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Dāvis]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #43 from Dāvis  ---
(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 receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #42 from Cqoicebordel  ---
(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 ;)

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Dāvis]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #41 from Dāvis  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Colin Griffith]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #40 from Colin Griffith  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #39 from Cqoicebordel  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Colin Griffith]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #38 from Colin Griffith  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #37 from Cqoicebordel  ---
I think that there is a setting for the amount of lines scrolled
https://i.imgur.com/CHmX5ms.png

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #36 from Nate Graham  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Colin Griffith]

https://bugs.kde.org/show_bug.cgi?id=386379

Colin Griffith  changed:

   What|Removed |Added

 CC||tyna...@gmail.com

--- Comment #35 from Colin Griffith  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Thomas Käfer]

https://bugs.kde.org/show_bug.cgi?id=386379

Thomas Käfer  changed:

   What|Removed |Added

 CC||kaef...@gmail.com

--- Comment #34 from Thomas Käfer  ---
Observing this issue @ Manjaro Linux with
Dolphin 18.12.1
KDE Frameworks 5.54.0
Qt 5.12.0
libinput 1.12.5-1

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Dāvis]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #33 from Dāvis  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Dāvis]

https://bugs.kde.org/show_bug.cgi?id=386379

Dāvis  changed:

   What|Removed |Added

 CC||davis...@gmail.com

--- Comment #32 from Dāvis  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #31 from Cqoicebordel  ---
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)

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #30 from Nate Graham  ---
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. :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #29 from Cqoicebordel  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Patrick Silva]

https://bugs.kde.org/show_bug.cgi?id=386379

Patrick Silva  changed:

   What|Removed |Added

Version|18.08.1 |18.12.1

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Gabriel B]

https://bugs.kde.org/show_bug.cgi?id=386379

Gabriel B  changed:

   What|Removed |Added

 CC||juangabo+kdeBugtracking@gma
   ||il.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #28 from Cqoicebordel  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Mark]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #27 from Mark  ---
@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+).

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Patrick Silva]

https://bugs.kde.org/show_bug.cgi?id=386379

Patrick Silva  changed:

   What|Removed |Added

 CC||mark...@gmail.com

--- Comment #26 from Patrick Silva  ---
*** Bug 401626 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[kdedroid]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #25 from kdedroid  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #24 from Nate Graham  ---
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!

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[kdedroid]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #23 from kdedroid  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #22 from Nate Graham  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[kdedroid]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #21 from kdedroid  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #20 from Nate Graham  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[kdedroid]

https://bugs.kde.org/show_bug.cgi?id=386379

kdedroid  changed:

   What|Removed |Added

 CC||offroa...@kripter.io

--- Comment #19 from kdedroid  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Dr . Chapatin]

https://bugs.kde.org/show_bug.cgi?id=386379

Dr. Chapatin  changed:

   What|Removed |Added

Version|18.04.1 |18.08.1

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Stephen Kendall]

https://bugs.kde.org/show_bug.cgi?id=386379

Stephen Kendall  changed:

   What|Removed |Added

 CC||technin...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #18 from Nate Graham  ---
Relevant files are:

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

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[francesco]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #17 from francesco  ---
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 ...

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[francesco]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #16 from francesco  ---
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 ...

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #15 from Nate Graham  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[whoopsdecade]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #14 from whoopsdecade  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Dr . Chapatin]

https://bugs.kde.org/show_bug.cgi?id=386379

Dr. Chapatin  changed:

   What|Removed |Added

Version|17.12.3 |18.04.1

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Todor Gyumyushev]

https://bugs.kde.org/show_bug.cgi?id=386379

Todor Gyumyushev  changed:

   What|Removed |Added

 CC||yo...@developer.bg

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[mthw0]

https://bugs.kde.org/show_bug.cgi?id=386379

mthw0  changed:

   What|Removed |Added

 CC||jari...@hotmail.com
Version|17.08.2 |17.12.3

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

Nate Graham  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=223937

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[francesco]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #13 from francesco  ---
@Cqoicebordel I agree 100% with you: scroll should not based on icon size
that's the issue here.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Dr . Chapatin]

https://bugs.kde.org/show_bug.cgi?id=386379

Dr. Chapatin  changed:

   What|Removed |Added

 CC||jcdop...@gmail.com

--- Comment #12 from Dr. Chapatin  ---
*** Bug 392363 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #11 from Cqoicebordel  ---
In the same way, it seems that scrolling on the desktop switch multiple virtual
desktops for the same reason.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #10 from Cqoicebordel  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[francesco]

https://bugs.kde.org/show_bug.cgi?id=386379

francesco  changed:

   What|Removed |Added

 CC||postadelm...@gmail.com

--- Comment #9 from francesco  ---
I confirm this problem is still present on plasma 5.12.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[GuHua]

https://bugs.kde.org/show_bug.cgi?id=386379

GuHua  changed:

   What|Removed |Added

 CC||renyune...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Marco Martin]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #8 from Marco Martin  ---
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-1src/kitemviews/kitemlistcontainer.cpp
M  +1-1src/kitemviews/kitemlistview.cpp
M  +8-0src/kitemviews/private/kitemlistsizehintresolver.cpp
M  +2-0src/kitemviews/private/kitemlistsizehintresolver.h

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

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

--- Comment #6 from Nate Graham  ---
There's a patch undergoing review that should fix this:
https://phabricator.kde.org/D10102

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Cqoicebordel]

https://bugs.kde.org/show_bug.cgi?id=386379

Cqoicebordel  changed:

   What|Removed |Added

 CC||david.bar...@wanadoo.fr

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=386379

Nate Graham  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED
Summary|Scrolling is faster |Dolphin scrolls faster in
   |comparing with other|icon mode than other Qt/KDE
   |softwares   |software

--- Comment #5 from Nate Graham  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.