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 737175 - most horizontal sliders are inverted when scrolled with mouse wheel
most horizontal sliders are inverted when scrolled with mouse wheel
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkRange
3.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-09-23 13:16 UTC by Branko Grubic (bitlord)
Modified: 2017-12-19 21:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GtkRange: fix horizontal scrolling (824 bytes, patch)
2015-04-15 13:28 UTC, Lars Karlitski
committed Details | Review
Range: Fix inverted vert scrolling on horiz Ranges (1.22 KB, patch)
2017-12-19 18:35 UTC, Daniel Boles
committed Details | Review
Range: Fix inverted vert scrolling on vert Ranges… (1.24 KB, patch)
2017-12-19 21:10 UTC, Daniel Boles
committed Details | Review

Description Branko Grubic (bitlord) 2014-09-23 13:16:25 UTC
In most applications horizontal sliders react inverted on scroll functionality, examples are rhythmbox (song progress slider), gnome-control-center (sound, keyboard, mouse&touchpad,...). If you move the mouse cursor over the slider and scroll UP you expect it to increase value (song go +xx seconds ..., mouse speed goes UP (faster), keyboard delay, speed, cursor blinking, volume up/higher), but everything goes down to lower values. I'm not sure if I selected right component for this, please re-assign if needed.
Also very important in gnome-shell user/power menu (top right corner) there are two sliders on my system for brightness and volume they work as expected (scroll UP they increase values, scroll DOWN they decrease value), so inverted compared to those inside applications, control-center settings... 

This is tested on f21 (3.13.92), same behavior with external mouse, or touchpad (edge scrolling)
Comment 1 Lars Karlitski 2015-04-15 13:28:19 UTC
Created attachment 301629 [details] [review]
GtkRange: fix horizontal scrolling
Comment 2 Matthias Clasen 2015-04-17 15:01:46 UTC
Attachment 301629 [details] pushed as 422d872 - GtkRange: fix horizontal scrolling
Comment 3 Daniel Boles 2017-10-14 16:52:37 UTC
What relevance did this patch have to the reported bug?

The bug was this:
 * Scrolling UP currently causes a decrement in value, but it should increment.

What was changed here was this:
 * Scrolling LEFT should cause a decrement in value.

The latter is correct, but it doesn't address the former, which is still present and still counter to nearly everyone's expectations, I would imagine.

Bug 788905 addresses horizontal scrolling causing the value to change in the wrong direction, and the patch I'm currently testing for that also fixes this.
Comment 4 Daniel Boles 2017-10-14 17:40:41 UTC
nevermind, I had forgotten that vertical Ranges default to the lower bound being at the top and the upper at the bottom; the first thing I do when using a vertical Range is to set is as inverted to fix that.

So, there's still a bug, but it's not the one reported here - closing to put the fix for that in Bug 788905
Comment 5 Daniel Boles 2017-12-19 11:39:13 UTC
(In reply to Daniel Boles from comment #3)
>  * Scrolling UP currently causes a decrement in value, but it should
> increment.

This is still an issue, on the path that uses scroll directions (not precise deltas).

I'm on win32, which uses this path (unlike GNOME), and scrolling the mouse up/down on a horizontal Scale cause movement left/right, which indicates there's *still* a bug here, despite the many patches that have tried to resolve it...


The offending path appears to be this:

  else if (gdk_event_get_scroll_direction ((GdkEvent *) event, &direction))
    {
      if (direction == GDK_SCROLL_UP ||
          direction == GDK_SCROLL_LEFT)
        delta = - scroll_unit;
      else
        delta = scroll_unit;

Surely that UP should be a DOWN? We want Up to convey 'more'.


Note that the same logic should also apply to key events, which it currently doesn't, but that's a long-standing bug: Bug 407242
Comment 6 Daniel Boles 2017-12-19 18:35:59 UTC
Created attachment 365759 [details] [review]
Range: Fix inverted vert scrolling on horiz Ranges

Various patches have hit this area, but the path using directions was
still negating the delta/decreasing the value as the wheel scrolled up.
This is unintuitive & also inconsistent with the path that uses deltas.
The wrong behaviour could be observed on e.g. win32 or X11 without WI2.

So, only negate the delta when scrolling down (or left), not up, so that
scrolling up (or right) will make the value increase for any event type.

https://bugzilla.gnome.org/show_bug.cgi?id=737175#c5
Comment 7 Carlos Garnacho 2017-12-19 18:55:10 UTC
Review of attachment 365759 [details] [review]:

+1, looks consistent with the smooth scroll paths
Comment 8 Daniel Boles 2017-12-19 18:59:48 UTC
Attachment 365759 [details] pushed as 4d18a34 - Range: Fix inverted vert scrolling on horiz Ranges


Thanks!
Comment 9 Daniel Boles 2017-12-19 21:10:10 UTC
Created attachment 365771 [details] [review]
Range: Fix inverted vert scrolling on vert Ranges…

The change in the previous patch should only be applied when the Range
is oriented horizontally.
Comment 10 Daniel Boles 2017-12-19 21:10:31 UTC
Let's try that again without breaking vertical ranges into the bargain this time.

Note that inverted horizontal ranges still scroll the wrong way, XI2 or not.
Comment 11 Daniel Boles 2017-12-19 21:22:14 UTC
Attachment 365771 [details] pushed as 0e338d3 - Range: Fix inverted vert scrolling on vert Ranges…


2nd time lucky... now onto all the other, related oddities.