GNOME Bugzilla – Bug 91961
Scrollwheel on volume bar works reversed
Last modified: 2015-06-21 15:11:16 UTC
If you use the mouse scrollwheel while the pointer is above the volume control, it appears that it works in a reversed way compared to what you would expect. If you scroll "upwards" the volume decreases. And vice versa. Could it be affected by Totem, or is it hardwired to gtk2?
Reassigning to GTK+. I could reproduce it with gtk+ 2.0.6-1. A non-inverted HScale will decrease the value with "Wheel up" and increase it with "Wheel down". I would expect the value to increase with "Wheel up" instead.
Changing component to gtk and changing bug assignement.
Could you compare bug 85436 and comment?
OK, I guess 84536 is about vscale, not hscale. If the scrollwheel is working the same way as the arrow keys, then the scrollwheel is working correctly. The arrow key direction is another question. I believe the logic here is that for, say, a blind user, it shouldn't matter whether a range is vertical or horizontal. And for a non-inverted vertical range, the behavior of up/down is constrained - down is the direction of increasing magnitude. I'd also have a strong expectation that scrolling down would move a scrollbar to the right, since for (LTR) reading Left/Top contrast to Bottom/Right. The fact that GTK+ ranges have down increasing tends to make people use inverted ranges for volume controls, because the standard convention for volume controls is opposite. Maybe we need some setitng on a scale "if this scale was vertical, I'd have made it inverted"?
Don't know if this should be a separate bug but... Another thing is that I would also expect that when I click the pointer on any place of the scale, the slide would go there. But it doesn't do that, it only does so if you click 3rd button. Instead it makes the slide move slightly towards the pointer. I could see the reason for the current behaviour, but couldn't this be conditional as well, depending on how the application developer thinks it should work?
The last thing is a different issue (if you care about it, file a separate bug report) and definitely should not be conditional on what the app developer thinks -- users are entitled to expect consistency between different applications. The current GTK+ behavior is standard across all toolkits for scrollbars; I haven't investigated scale widgets for other toolkits.
I'm still bugged with this using GTK 2.10(PyGTK) and using a HScale. Scrolling Up(Arrow-Up) decreases it and scrolling down(Arrow-Down) decreases it. If I use scale.set_inversed(True) the bahavior is as expected. (scroll-up = increase etc.)
I believe this has been fixed in gtk3