[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 
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 

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) :-)



Reply to: