Version: 1.99 (using Devel) OS: Linux One mousewheel step is scrolling more than the dolphin viewport height. Dolphin git20111011, but i can't find anything about scroll speed in commits since then. Reproducible: Always Steps to Reproduce: See video. Actual Results: Entries are skipped, the scroll is to fast. One mousewheel step is scrolling more than the dolphin viewport height. Expected Results: No entries skipped. One mousewheel step should scroll about 1/2 of the screen. At least, it should scroll less than one screen. Exact one height scrolling is bad too, in my opinion (harder to find files on the screen).
It is shown on the table view, but all views are affected (scroll is too fast).
http://oserv.org/bugs/dolphin-scroll-bug.ogv — the video. I couldn't attach it, it's 1083 KiB in size.
It's exactly 1 mousewheel step on that video.
Thanks for the report. I agree, the current step size (= exactly one page size) is too big. I'll decrease this...
Thanks ). But, to be accurate, it wasn't exactly one page size, it was page size + 1 row in the video. It's «gawk-4.0.0 grep groups» in the video (you can see it in the end or if you pause on the animation). Before scroll, «gawk-4.0.0» is the last one displayed. After scroll, «groups» is the first one. «grep» was lost completely.
>But, to be accurate, it wasn't exactly one page size, > it was page size + 1 row in the video Ah, you are right :-) This seems to be an issue only in the details-view because of the header and works in the icons-view... Will take care that the smaller wheel-steps work well in both views.
Git commit 0b85049d646cc32fa65a7e4cd5cb76770fc6ef5a by Peter Penz. Committed on 22/10/2011 at 12:33. Pushed by ppenz into branch 'master'. Mousewheel-support: Use smaller scroll-steps Use only 1/4 of the scrollbar-page-size when the mousewheel is used. BUG: 284646 FIXED-IN: 4.8.0 M +1 -1 dolphin/src/kitemviews/kitemlistcontainer.cpp http://commits.kde.org/kde-baseapps/0b85049d646cc32fa65a7e4cd5cb76770fc6ef5a
@Nikita: To me the new page-step size of using 1/4 feels good, but I did not test it during a longer period. If you feel that it is too slow/fast please let me know.
Ok, i recompiled dolphin from git. Scroll looks much nicer for me now, thanks! I'll use it on two computers (eeepc with a touchpad and a desktop + logitech mouse with fast/normal scrolling). I'll post here, if there would be any problems for me. There are some other minor bugs, like: *) Almost invisible selected filenames background on bad (laptop) screens (eeepc). Looks fine on a desktop IPS screen. This should look good on all screens. *) I'm not sure if i like how selected items in tableview are highlighted. Small icons have bright background, the text (main part) does not. Maybe this will look good once the previous point (selected names background) gets fixed. *) Filter (ctrl-i) does not work. *) Maybe not dolphin is the cause: changing kde colorscheme applies to running dolphin only partially. Half of the rows in table view use old colors until dolphin restart. *) No expand arrows in root folder. *) Table -> Icons view toggle has wrong animation. *) Some minor animation glitches (didn't check after update). *) Personally, i liked old expand arrows (and lines) more. Overall, dolphin 2.0 looks great! Should i file separate bug report about #1 (selected filenames background)?
Thanks for the feedback. Usually mixing other bug-reports in a given report is not good, as you won't get any automatic feedback which bug will get fixed... But in very short: I'm aware about all issues you've mentioned here, I hope I can fix them until 4.8.0. If some of those bugs are still there after the first release candidate got released it would be great if you could submit bug-reports for each of the remaining issue :-)
Thanks, that's what i thought. I didn't submit separate bug-reports and asked first because of that :-). I'll check everything after an RC and file a bug-report if i will notice anything.
Shouldn’t the setting from systemsettings be respected, i.e. the amount of rows it scrolls?