New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjusting mouse wheel scroll rate #1361

Closed
randomizer101 opened this Issue Nov 13, 2012 · 11 comments

Comments

Projects
None yet
5 participants
@randomizer101

randomizer101 commented Nov 13, 2012

It would be nice if there was a way to adjust the number of lines scrolled per "notch" of the scroll wheel on the mouse, or some similar metric (even a multiplier on top of the base number of lines?). I don't think GNOME has ever included such an option, at least since 2.x, while KDE has had it for a long time, so I think it would be a welcome addition to Cinnamon. This might be a difficult task though if the limitations are in GTK and can't be worked around at a higher level.

I know that you can set the scroll rate in Firefox which is fantastic. That doesn't help other applications like LibreOffice though. Scrolling through a 60 page document 3 lines at a time is painful.

@wrouesnel

This comment has been minimized.

Contributor

wrouesnel commented Nov 14, 2012

Technically it's an X windows issue, since X represents the mouse-wheel to the toolkits, which in turn make a decision about how they interpret it.

The xorg people don't seem to have much of an idea about what they want to do about it - the problem being that mouse wheel's have been treated as button axes for so long no one knows what to do about it, and the "correct" answer would be to make them axes...but then it depends on whether applications read the axes or mouse wheels.

I am somewhat confused as to why Canonical hasn't been kicking the X people to fix it though.

@randomizer101

This comment has been minimized.

randomizer101 commented Nov 14, 2012

Well the Qt/KDE developers managed to come up with a solution (at least for Qt applications) so it is clearly possible, even if it's not completely flawless. Of course you could quite possibly run into trouble ensuring consistent behaviour between applications using different toolkits.

@wrouesnel

This comment has been minimized.

Contributor

wrouesnel commented Nov 15, 2012

As a follow up to this, I posted a question to the xorg mailing list. http://lists.x.org/archives/xorg/2012-November/055060.html).

Looking around, it looks like KDE would be doing it via the Qt libraries, and there's nothing implemented for GTK yet.

@Xethron

This comment has been minimized.

Xethron commented Nov 19, 2012

Would really love to see this feature, as I have a R.A.T. 9 with horizontal scroll that really really slow!!!

@randomizer101

This comment has been minimized.

randomizer101 commented Apr 28, 2013

I decided to have a look into this myself. I managed to work out where the scroll rate was set for some applications, but it seems that it is determined in several places. For example, I managed to change it for Nemo, but the change had no impact on Gedit, LibreOffice and Firefox (the latter I'm expecting issues with as I know that it tends to override things). Unfortunately I have zero knowledge about the bowels of GTK+ so I am pretty much stabbing in the dark.

@QuantumInformation

This comment has been minimized.

QuantumInformation commented Dec 19, 2013

this really needs to be improved, 3 lines a scroll is way to slow

@Xethron

This comment has been minimized.

Xethron commented Dec 20, 2013

Maybe its possible to tell Cinnamon to multiply the scrolling by x? So, pass through that the wheel scrolled twice when in fact it only scrolled once?

This way you might not be able to get the 4 or 8 lines you hoped for, but you can get 3, 6, 9, 12........ at a time?

Just an idea. I don't really care how many characters my R.A.T scrolls sideways, I just want it to be more than it is currently. Much more!

@randomizer101

This comment has been minimized.

randomizer101 commented Dec 20, 2013

The trouble is that it's not a static 3 lines that are scrolled. The amount depends on the height of the window. Simply multiplying by a fixed multiplier may make small windows scroll nicely, but large windows would be uncontrollable. Conversely, a multiplier that works well on large windows may have little impact on small windows.

@wrouesnel

This comment has been minimized.

Contributor

wrouesnel commented Dec 20, 2013

What's really needed is mouse wheel acceleration - this is how Windows
does it. The word from the X. Org people is they think toolkits should
handle this - which I guess isn't really wrong, but it means there's no
fix coming from upstream and it's a problem today.

On Fri 20 Dec 2013 21:52:16 EST, randomizer101 wrote:

The trouble is that it's not a static 3 lines that are scrolled. The
amount depends on the height of the window. Simply multiplying by a
fixed multiplier may make small windows scroll nicely, but large
windows would be uncontrollable. Conversely, a multiplier that works
well on large windows may have little impact on small windows.


Reply to this email directly or view it on GitHub
#1361 (comment).

@randomizer101

This comment has been minimized.

randomizer101 commented Dec 20, 2013

The toolkits do handle it. Qt just does it better because the user is in control and not an automagic algorithm that only works for windows under 300px high..

@dalcde

This comment has been minimized.

Contributor

dalcde commented Apr 16, 2015

afaik individual applications decide what to do with scroll events. I can write an application that totally ignores scroll events. It works with Qt applications since Qt applications let Qt to decide what to do, and Qt allows you to change the behaviour. Sometimes you can change it via some xorg settings, but depends a lot on exactly what input device you are using. Closing unless there is a valid universal solution.

@dalcde dalcde closed this Apr 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment