https://bugs.kde.org/show_bug.cgi?id=386379
--- Comment #45 from Colin Griffith <tyna...@gmail.com> --- (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.
