After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 739806 - scale use wrong direction when use natural scrolling feature
scale use wrong direction when use natural scrolling feature
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkRange
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-11-08 05:38 UTC by LiuPai
Modified: 2018-05-02 16:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description LiuPai 2014-11-08 05:38:50 UTC
When check natural scrolling feature, scroll on the scales need scroll to the opposite, this is not the *natural* way.
Comment 1 Daniel Boles 2017-02-17 19:24:06 UTC
afaict, GTK+/GDK just works with the scroll events it's given, after possible inversion by the system. That is: it has no way to check whether the user prefers 'natural scrolling'. So it can't conditionally re(-in)vert the scroll direction for certain cases where that is semantically better. Hence what you reported here.

If that's right, the question is then whether the maintainers would want to add a way for GTK+ to get whether natural scrolling is on, and conditionally avoid it for certain cases where it degrades UX.
Comment 2 Eric Polin 2017-02-17 20:35:10 UTC
Workaround:
synclient | grep ScrollDelta
synclient VertScrollDelta=-<formerValue> HorizScrollDelta=-<formerValue>
Comment 3 Daniel Boles 2017-02-17 20:45:00 UTC
Eric: Please can you clarify

 (A) how that helps this. Doesn't it just re-invert scrolling system-wide?

 (B) whether your Bug 760569 is still an issue? Evolution does what I expect
     in both 'normal' and natural modes, as do other GTK+ 3 applications. So
     unless I have missed something, that ticket can be closed.
Comment 4 Eric Polin 2017-02-17 20:55:28 UTC
I don't know about the various layers of code involved, but obviously the behaviour needs to be consistent whatever the application.

So, the "natural scrolling" check box should indeed reverse scrolling system-wide instead of doing whatever more sophisticated but less effective thing it does.
Comment 5 Daniel Boles 2017-02-17 21:00:50 UTC
That doesn't answer either of my questions, but OK

I think you have it exactly backwards. The problem reported in this bug is that GTK+ DOES invert the scrolled direction for all widgets when natural scrolling is turned on at the DE level.

The point is that isn't very nice when you find that scrolling up while hovering over a GtkRange causes the value to be DEcreased.
Comment 6 Eric Polin 2017-02-23 11:08:02 UTC
Sorry about my irrelevance about that bug: I am only finding now that it is about the widget itself; indeed, scrollbars, for example, behave properly, whether the system scrolling is direct or reverse.
Pls feel free to erase my comments if it helps for clarity.
As for Bug 760569, it is still there on my version. I am going to update it.
Comment 7 GNOME Infrastructure Team 2018-05-02 16:17:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/514.