Bug 188757

Summary:	Inadequate list view scrolling
Product:	[Unmaintained] kdelibs	Reporter:	Michael Reiher <redm>
Component:	kdeui	Assignee:	kdelibs bugs <kdelibs-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	b, bugzilla, ch75, elvis.angelaccio, kde, kdebugs.99.urgwurz, matej, nightowl, oliver.henshaw, sami.kyostila, vo.zaeb
Priority:	NOR
Version:	4.2
Target Milestone:	---
Platform:	Ubuntu
OS:	Unspecified
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Michael Reiher 2009-04-03 19:07:33 UTC

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.

Comment 1 Christoph Feck 2009-04-04 03:47:50 UTC

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

Comment 2 Tanja Schulte 2009-08-02 20:28:14 UTC

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

Comment 3 Tanja Schulte 2009-08-02 20:37:40 UTC

Maybe Bug 195342 is a duplicate too? At least related.

Comment 4 Tanja Schulte 2009-08-02 21:43:28 UTC

And another one: Bug 192049 ?

Comment 5 Cedric 2009-08-08 15:16:34 UTC

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.

Comment 6 Christoph Feck 2010-01-04 13:53:50 UTC

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

Comment 7 Christoph Feck 2010-01-04 13:55:30 UTC

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

Comment 8 Christoph Feck 2010-01-04 13:56:34 UTC

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

Comment 9 Christoph Feck 2010-01-29 02:10:37 UTC

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

Comment 10 Frederik Gladhorn 2010-04-01 14:58:12 UTC

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

Comment 11 Christoph Feck 2010-07-08 14:21:11 UTC

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

Comment 12 Alexander 2010-07-08 15:59:13 UTC

Seems that here https://bugs.kde.org/show_bug.cgi?id=243933 I've described a slightly different problem.

Comment 13 Christoph Feck 2010-08-31 23:50:51 UTC

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.

Comment 14 Christoph Feck 2012-02-18 14:35:45 UTC

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.

Comment 15 Christoph Feck 2012-03-08 18:20:13 UTC

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

Comment 16 Elvis Angelaccio 2016-12-22 17:17:59 UTC

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.