Version: (using KDE 4.2.2) Installed from: Ubuntu Packages Scrolling in list views is somewhat suboptimal, perhaps you could call it even broken. List views scoll per default three items per wheel click (scroll click, not MMB click). This was no problem for old style list views, where items used to have the hight of a text line, more or less. However with KDE4 you have these new style list views all over the place which have much bigger items, with multiple lines of text or images. Examples are the Plasmoid selector in plasma, GHNS or the like. Here with with one wheel event the list jumps a really big distance. This lets the user loose the context of where he is in the list. While in some cases it's taken care that you don't actually miss items (if the view height is less than 3 items), it leaves an ungood feeling that you do. An extreme example is the package list of Kubuntus Kpackagekit. If you click an item in it, it gets unfolded becoming about 3 times as big as a normal (already big) item, still it scrolls 3 items (so this would be around 5 of the normal items per wheel event). Another is the wallpaper GHNS dialog, which jumps a total of 6 items. In both cases even if the view is smaller than this total height, meaning you actually miss items, in addition to the loss of context. In System Settings you can adjust the number of items to scroll. However, setting it to 1 item while giving acceptable scrolling for new style list views, it gives unaccaptable slow scrolling in old style list views and even KHTML somehow... So IMHO the list views shouln't scroll in a fixed number of items, but in a certain percentage of the height of the view. An alternative would be smooth scrolling. Though this doen't fix the missing of items.
*** Bug 185193 has been marked as a duplicate of this bug. ***
*** Bug 202319 has been marked as a duplicate of this bug. ***
Maybe Bug 195342 is a duplicate too? At least related.
And another one: Bug 192049 ?
I add my vote. I think the System Settings option unit should be "pixel" rather than "percentage of height view" as suggested or "number of lines/items" as it is now.
*** Bug 221153 has been marked as a duplicate of this bug. ***
*** Bug 192049 has been marked as a duplicate of this bug. ***
*** Bug 195342 has been marked as a duplicate of this bug. ***
*** Bug 224705 has been marked as a duplicate of this bug. ***
SVN commit 1109982 by gladhorn: Fix scrolling in KNewStuff3 for KDE 4.5 Since http://bugreports.qt.nokia.com/browse/QTBUG-7232 seems to stay open, here is a workaround: in the wheelEvent, set the step size of the scrollbar, this should be relative to the item heigt. void ItemsView::wheelEvent(QWheelEvent* event) { // this is a workaround because scrolling by mouse wheel is broken in Qt list views for big items verticalScrollBar()->setSingleStep(itemHeight / 10); QListView::wheelEvent(event); } CCBUG: 188757 M +1 -0 CMakeLists.txt M +12 -1 downloadwidget.ui A ui/itemsview.cpp [License: LGPL (v2.1+)] A ui/itemsview.h [License: LGPL (v2.1+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=1109982
*** Bug 243933 has been marked as a duplicate of this bug. ***
Seems that here https://bugs.kde.org/show_bug.cgi?id=243933 I've described a slightly different problem.
Alexander, it is the same problem. On the screen shots you posted, it scrolls an entire page when the wheel is only moved by one "click". Users suggested to change the wheel scrolling delta to think in number of pixels, rather then lines, because that way the perceived scrolling speed would stay the same regardless of item size. This eases mental recognition of the scrolling process. For the presented use case, it should probably even scroll a single "line" (i.e. one image row) per wheel event. If I understood it wrong, please clarify.
Please vote/comment on https://bugreports.qt-project.org/browse/QTBUG-7232 If you do not, Qt developers will probably forget about users using a mouse with a scroll wheel, and instead assume that everyone likes finger based interfaces.
*** Bug 295544 has been marked as a duplicate of this bug. ***
The upstream bug report has been fixed in Qt 5.7.0: https://bugreports.qt.io/browse/QTBUG-7232 Quoting from there: "This issue is being closed because Qt 4.8.x is no longer receiving patches other than security fixes. Please see the mailing list thread for more information:" This means there is nothing we can do from the kdelibs side.