https://bugs.kde.org/show_bug.cgi?id=386379
--- Comment #53 from Riccardo Robecchi <sephiroth...@hotmail.it> --- (In reply to Nate Graham from comment #51) > We just implemented the standard line-of-text-based scroll behavior for > Dolphin, making it consistent with everything else. Nate, I understand this reason and I approve it. But let me give you another perspective: what is consistency? We can define it in two ways: 1. the actual same behaviour applied to everything, independent of the usage or the specific requirements; 2. the same perceived behaviour, which is however different in terms of how it's implemented. The first is technical consistency, the second is UX/behaviour consistency. Scrolling text is different than scrolling a list of icons, especially when the latter can be made of especially large icons which take up the space of several lines of text. It's easy to see that the behaviour which may be entirely fine when scrolling text can not be entirely fine when scrolling icons in a file manager. I think that in this case what is important is the UX, not the technical consistency, especially since there is no easy way to change this annoying behaviour. I'll make a specific case for the current behaviour not to be the default. Imagine you come from Windows (and we know there are lots of people migrating from Windows 7 right now!), where scrolling is not like that of current Dolphin. You realise how tedious it is to do an easy and basic thing such as scrolling through the files in a folder. I, as a user, would immediately flee the platform and go after something else, because the alternative would be to fiddle with non-trivial stuff such as removing libinput in favour of evdev (though that could break other stuff!) or fiddling with the xorg.conf file (which is not something I would want a newbie to do as their welcome to the KDE world!). > In other words, this problem is not specific to Dolphin and needs to be > fixed at a lower level. Personally I favor adding a scroll speed setting to > Libinput and implementing acceleration for very fast wheel movements. > > Those requests would need to be made in the Libinput project of course. I understand that. But what if Libinput never offers scroll speed settings, or does so in two years? Are we going to keep Dolphin with a broken behaviour just because Libinput is "broken" (from this specific usability perspective)? My point is: wouldn't this proposed "fix" be better suited for when we have the actual correct implementation of Libinput (or whatever is needed at a lower level) available? At the moment we have two broken things, Dolphin and the mouse settings using Libinput, instead of just one, the mouse settings using Libinput. Would it be possible to work on a different solution, at least until we have working Libinput? -- You are receiving this mail because: You are watching all bug changes.
