Scrolling trough some lists with the mouse wheel only moves the visible part of a list by a few pixels. When i scroll 4 steps on the mouse wheel, i see only the half of a new list-entry, with the text cut in half horizontally. Lists i have noticed that this applies to: * application starter > history * Klipper history in the Klipper applet * the list of applets shown when adding a new applet to a taskbar, or the desktop AFAIK all of these are shown by plasmashell. Note that scrolling in applications such as dolphin and konsole works at a normal speed. Also, please don't show entries cut in half. These lists should work like scrolling through output in the konsole terminal, which never shows half a line, and jumps exactly to the start/end of a line. Also, the length of these lists should be such that no cut in half entries are shown, ever. Observe how the konsole terminal does this perfectly when you are resizing it vertically.
*** Bug 375009 has been marked as a duplicate of this bug. ***
Can't reproduce. What Qt version is this? I recall Qt before some version not respecting wheel scroll lines. As for delegates not cut in half, that's not easily possible, if at all. Konsole is a bad example to compare those lists with. It doesn't have section headers and is just a dumb unformatted list of text.
Qt is from archlinux package qt5-base 5.7.1-2 Note that Qt applications like "QDBusViewer" scroll exactly by the number of lines configured in the settings.
*** Bug 373747 has been marked as a duplicate of this bug. ***
This is a combo bug in both Qt's XCB backend and ScrollArea in QtQuickControls scrolling has two modes, moving by n pixels or by n "ticks". In QWheelEvent terms: - pixelDelta and angleDelta A libinput change has meant that Qt's detection of "is it a scroll wheel or not" is broken. I think libinput seems to trying to artificially say how far things should scroll at an input level rather than it being up to the application. In QXcbConnection::xi2HandleScrollEvent scrollingDevice.verticalIncrement is 15 . This matches what I see in xinput list which shows: Class originated from: 11. Type: XIScrollClass Scroll info for Valuator 2 type: 2 (horizontal) increment: 15.000000 flags: 0x0 We then go into the // We do not set "pixel" delta if it is only measured in ticks. if (scrollingDevice.horizontalIncrement > 1) rawDelta.setX(delta); In most Qt code this isn't a problem. Either pixel delta is ignored or it looks about right anyway In QtQuickControls QtQuickWheelArea we have a huge bug; as we now have valid pixelDelta we go into a different code path that ignores the user scrollspeed. It then randomly divides things by 2 to match some OS X behaviour. This is what leads to things being slow and corrupted fonts. I'll probably have to close this as upstream once I file a bug report there.
*** Bug 376873 has been marked as a duplicate of this bug. ***
*** Bug 378812 has been marked as a duplicate of this bug. ***
Upstream bug report: https://bugreports.qt.io/browse/QTBUG-59261
*** Bug 355410 has been marked as a duplicate of this bug. ***
On Arch plasma-desktop 5.11.5-1 the problem is still present ( dolphin scroll is super fast ) When should we expect this fix to land on plasma ? ( does anyone actually tested the upstream fix on KDE ? aka are we sure this has been actually fixed ? )
patch was already applied on Arch https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/qt5-base&id=9b3d7b002d65ef759c60a71fa12e006ecc0b271c bug 386379 is about dolphin
So it looks to me there is still some issue here as the scroll in Dolphin is much faster that in a Chrome webpage or in Okular. It appears to me that Dolphin consider a row "a rows of files" and so each wheel/scroll advancement is related to the file row's height: - So if you have an high zoom level in dolphin view the scroll is super fast. To test this behaviour you can use also the arrow keys as basically the mouse scroll and key arrow scroll behave the same way. I am not an expert of UI but I think this is not the correct behaviour.
(In reply to francesco from comment #11) > On Arch plasma-desktop 5.11.5-1 the problem is still present ( dolphin > scroll is super fast ) > > When should we expect this fix to land on plasma ? > ( does anyone actually tested the upstream fix on KDE ? aka are we sure this > has been actually fixed ? ) I'm on Arch plasma-desktop 5.12.0-1 , qt5-base 5.10.0-4 and the problem is still here not sure if the upstream patch is resolving the super fast dolphin scroll. Should this bug be submitted to Dolphin ?
Todor, read comment 12.
I confirm it is still present on Plasma 5.12.0
*** Bug 392632 has been marked as a duplicate of this bug. ***