Re: X Window: Setting up mouse scroll for OOo Calc to one raw
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
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
> 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
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) :-)