| Summary: | Scrolling through plasmashell lists is too slow, shows entries cut in half | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Lukas Ba. <kdeu> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | abderrahman.najjar, bhush94, bugseforuns, elvis.angelaccio, kde, kishore96, kollix, marcinkolenda419, plasma-bugs, postadelmaga, ukyoi, ville.aakko, wulf.richartz, yodor |
| Priority: | NOR | ||
| Version: | 5.8.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugreports.qt.io/browse/QTBUG-59261 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Lukas Ba.
2017-01-15 00:12:55 UTC
*** Bug 375009 has been marked as a duplicate of this bug. *** *** 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. *** |