On Tue, 03 Jan 2012 10:44:12 +1300, Richard Hector wrote: > On 03/01/12 04:55, Camaleón wrote: >> But the best thing is that there is a patch already done for having the >> "feature" implemented at Xorg. > > I haven't re-read the bug report, but my impression was that someone has > written a patch, but it hasn't been accepted, and there was dispute > about it, so there's no guarantee it's going to get in.
The bug report states it is in a review process... but to be sincere, I don't mind the patch is accepted or not. The important thing (from my POV, of course) is that it can be done and that's enough (again, for me) :-) I don't have the need of increasing the wheel scroll speed, but it would be nice to have such option, of course. That's something users are requesting a lot... >>> > It seems to me that if the OP of that bug succeeds, all you'd get is >>> > _more_ lines/rows of scroll, not fewer - it would still need changes >>> > in the app. >> Wheel sroll speed is slow (at least with my basic 3 button mouse I also >> barely get 3 lines up/down which can be quite annoying depending on the >> document lentgh). But if there is a patch to speed it up, I see no >> compeling reason for not having the opposite and make the wheel scrolls >> slowly. > > The patch allows for faster scrolling by sending multiple events for > each wheel click. How do you send less than 1 (but more than 0) clicks? I have not read the patch code but how about by reducing (dividing/ substracting/fractioning operations) the events? >>> > But I'm inclined to agree with the other view, that the mouse wheel >>> > just gives button events, and it's up to the app to interpret them - >>> > possibly referring to a system-wide (or DE-wide) configuration - >>> > since it clearly means something different depending on the type of >>> > app. >> I don't share that POV. >> >> IMO, it will be desiderable to be possible to tweak both options: one >> (system wide) that affects all applications managed via Xorg's mouse >> driver and also having the possibility to control wheel speed for every >> application. This will result in a fine grained configuration that will >> suit every user need. > > Desirable, perhaps. Feasible, I don't think so. In the end it seems to be perfectly feasible: 1/ KDE (maybe because of Qt?) users already have such option 2/ There is a generic patch (evdev) for Xorg to implement it > It seems to me the real problem is that the wheel just isn't as fine > -grained as the movement of the mouse - my mouse appears to have 24 > clicks/rotation, and it has no way to measure smaller movements than > that. So the only adjustment possible is how far per click, and that > needs to be measured differently depending on whether the app is > (viewed as being) explicitly line based, the way the OP wants to see > their spreadsheet, or effectively continuous. And that's up to both the > app and the user, and changing what happens in the driver can only > reduce the options for those. IMHO. I don't understand why you think it's something so hard to get. Look, I have next to me my windows computer with a tree-button mouse (2 buttons+wheel) from the same brand and model I use with lenny and using the default mouse driver (the one that comes with the OS). Okay, so I have set there the mouse wheel scrolls down/up 3 lines at a time (whatever-that-means-for-windows) and when I open a spreadsheet and I scroll down I jump from raw 1 to raw 3. Fine. Now I configure the wheel to jump "one page" at a time (whatever-that- means-for-windows), go to the same spreadsheet and scrolling down takes me from raw 1 to raw 64. That's a hughe gain for sheets with thousand of records. Yes, yes... windows is windows and linux is linux. I agree. But the source of this problem shares the same nature (I can be wrong but I don't think the mouse is treated so differently in both systems, it's a very basic input device, nothing fancy) :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2012.01.03.17.01...@gmail.com
