Seems that https://bugs.kde.org/show_bug.cgi?id=357618 is not fixed completely the sidebars "places" and "folders" are still slow while scrolling for me, with latest git. Reproducible: Always Steps to Reproduce: 1. build dolphin from git 2. use libinput as Xorg server input 3. open dolphin 4. press F7 and F9 to open the folder and places sidebars (if not already there 5. try to scroll Actual Results: it scrolls very slooooowww Expected Results: it should scroll like the dolphin main windows scrolls now in git ;) its not a real duplicate of https://bugs.kde.org/show_bug.cgi?id=357618 .. its just that this one is marked as fixed and nobody seems to look at it anymore
I can confirm. Here is my topic about this issue on Antergos (Arch-based) https://forum.antergos.com/topic/3390/mouse-wheel-scrolling-in-dolphin-and-wallpapers-list-is-slower-than-in-internet-browsers
I'm not using xf86-input-libinput and started experiencing this issue on multiple machines in Dolphin 16.08.0 [Arch Linux 64bit]. To reiterate: the Folder and Places Panels are largely unusable now. Scrolling the entire length of my finger, causes the area to scroll about half a row. [I haven't noticed slow scrolling anywhere else.] So far, I haven't been able to find any workarounds. I tried the classical suggestions: switching Group View or Hidden Files on and off, installing/removing input drivers, etc.
Created attachment 100994 [details] Results of a single "full finger" scroll.
I have this issue also on multiple Manjaro/Arch machines, not using xf86-input-libinput. The bug came with version 16.08 (this includes 16.07.80 + 16.07.90). Can someone verify this? Version 16.04 works fine for me, as temporary workaround you could downgrade the dolphin package without big problems.
I can confirm this. Nobody mentioned, that this is about scrolling with mouse wheel, right?
It is for me.
Correct, mouse wheel only.
This bug seems similar: https://bugs.kde.org/show_bug.cgi?id=369286 He found out that commit "8d61c9c7b6f5a97803bf154529b413ee69bc2a1c" causes the problem and i can also confirm this! (last working commit 4fad4405a719a43968f0ff5e99b169cd5a81df5c) Apparently it was the fix for BUG: 357618, which was already mentioned by the OP.
I can confirm this bug. I am using dolphin 16.08.1-1 and xf86-input-libinput 0.20.0-1 on Arch Linux. I have found the following bugs that might be related: * #342839 Scrolling steps much too small in folders and places panels * #369286 dolphin 16.08.1's Mousewheel scrolling is very small at all settings in non-Plasma5-desktops (regression from 16.04) [cf. comment 8] * #355410 the scroll speed of QML scroll area is too slow with Libinput
*** This bug has been confirmed by popular vote. ***
@Martin Sandsmark: could you please have a look, what you broke by the mentioned commit? Perhaps revert it? Mouse wheel scrolling worked before without libinput.
(In reply to H.H. from comment #11) > @Martin Sandsmark: could you please have a look, what you broke by the > mentioned commit? Perhaps revert it? That would break again scrolling in the main folder view (with libinput).
But there was a workaround: uninstalling libinput, which should be not too hard.
(In reply to bugs.kde.org from comment #9) > * #369286 dolphin 16.08.1's Mousewheel scrolling is very small at all > settings in non-Plasma5-desktops (regression from 16.04) [cf. comment 8] I can confirm this is my use case as well; KDE in an OpenBox session. (In reply to H.H. from comment #13) > But there was a workaround: uninstalling libinput, which should be not too > hard. Please read the previous comments: neither Jake or myself have xf86-input-libinput installed. I'm using xf86-input-evdev.
(In reply to Tonurics from comment #14) > (In reply to H.H. from comment #13) > > But there was a workaround: uninstalling libinput, which should be not too > > hard. > > Please read the previous comments: neither Jake or myself have > xf86-input-libinput installed. I'm using xf86-input-evdev. My comment was about reverting the commit "8d61c9c7b6f5a97803bf154529b413ee69bc2a1c", which broke the only workaround, and so resulted in this bug. So having the possibility have xf86-input-libinput uninstalled and having xf86-input-evdev installed is all that would be needed, to have the workaround without the commit work. This bug is very annoying, please revert the commit, and next time do it without regressions.
(In reply to H.H. from comment #13) > But there was a workaround: uninstalling libinput, which should be not too > hard. libinput is required on wayland, so this would be a short-term workaround. But I agree that fixing the scroll with libinput should not break the scroll with the old driver..
(In reply to Elvis Angelaccio from comment #16) > libinput is required on wayland libinput and xf86-input-libinput are not the same. while all the QML stack on X11 is broken with xf86-input-libinput, it just works greate with libinput in wayland. The awefull situation right now is, that the X11 synaptics driver is not maintained anymore and on some setups even broken, so Distros just ship xf86-input-libinput to fix this and it works great on GTK+ Apps. Scrolling on some Qt-apps and all QML apps is broken because of this.
(In reply to FabiB from comment #17) > (In reply to Elvis Angelaccio from comment #16) > > libinput is required on wayland > libinput and xf86-input-libinput are not the same. Good point. I did another round of testing and this is what I see: * With the scroll fix applied (i.e. current master): - xf86-evdev, xf86-libinput, wayland-libinput: scroll is smooth in main panel, slow in dock panels * With the scroll fix reverted: - xf86-evdev: scroll is smooth in both main and dock panels - xf86-libinput: scroll is slow in both main and dock panels - wayland-libinput: scroll is smooth in both main and dock panels Can someone else confirm this matrix?
Hmm I think I found where the problem is. In KItemListContainer::updateScrollOffsetScrollBar() the PlacesPanel's view returns an invalid QSize as itemSize(), which results in a singleStep equal to -1
Patch up for review in https://git.reviewboard.kde.org/r/129409/
Thank you for the fix! I hope it will be applied soon!
Nice to see a patch! Finally usable again, but it is still a bit different on how much it scrolls from one mouse wheel step: without commit "8d61c9c...": - main and panels => 2-5 lines (depending on the dolphin window size!) latest git + patch: - main => 3 lines (always) - panels => 2 lines (always) systemsettings - scroll speed: 3 lines Distro: Manjaro, Desktop: KDE/Plasma 5, xf86-input-evdev Other experiences on different setups (xf86-libinput, non plasma desktop, ...)?
*** Bug 372673 has been marked as a duplicate of this bug. ***
Git commit 90beb4a5e37b887caad1e767046a42dad0af1ab3 by Elvis Angelaccio. Committed on 20/11/2016 at 11:59. Pushed by elvisangelaccio into branch 'Applications/16.12'. Fix slow scrolling in dock panels Commit f688bcd1f1 fixed slow scrolling with xf86-input-libinput on DolphinView. However the commit also exposed a bug in the Dolphin scrolling algorithm, which was previously hidden. This resulted in slow scrolling in dock panels (Places and Folders), with both xf86-input-evdev and xf86-input-libinput drivers, as well as libinput on Wayland. KItemListContainer::updateScrollOffsetScrollBar() relied on the view's itemSize() method to compute the scrollbar's singleStep, but this QSize was invalid for the dock panels' views. We use a new itemSizeHint() method instead, which is always valid and also adapts to the current icon size set in the view. FIXED-IN: 16.12.0 REVIEW: 129409 M +1 -1 src/kitemviews/kitemlistcontainer.cpp M +5 -0 src/kitemviews/kitemlistview.cpp M +6 -1 src/kitemviews/kitemlistview.h M +13 -0 src/kitemviews/private/kitemlistsizehintresolver.cpp M +2 -0 src/kitemviews/private/kitemlistsizehintresolver.h http://commits.kde.org/dolphin/90beb4a5e37b887caad1e767046a42dad0af1ab3
*** Bug 342839 has been marked as a duplicate of this bug. ***
*** Bug 375398 has been marked as a duplicate of this bug. ***