GNOME Bugzilla – Bug 703046
Volume slider moves into the wrong direction when scrolling
Last modified: 2021-06-09 16:29:30 UTC
Hovering the volume slider in Control Center (Gnome version 3.8.2) and scrolling with mouse/touchpad moves the slider into the opposite direction compared to the volume slider in the gnome-shell-panel. The slider should be adapted to scroll like the one in gnome-shell.
Created attachment 276170 [details] [review] Invert scroll direction of GvcChannelBar This patch only inverts the GvcChannelBar, not the balance bar. The patch may apply oddly, as there was a mix of tabs and spaces for indentation in that part of the file, and I wasn't sure whether to fix that in the same patch.
Created attachment 276171 [details] [review] Invert scroll direction of GvcChannelBar Whoops, attached a completely unrelated patch!
I can confirm this issue for master.
Just discovered this as well on GNOME 3.14.2 - quite a surprise that the same action has opposite effect in two places of the GNOME desktop.
This is still in issue in 3.18
It's shell doing things wrong actually. The concept of natural scrolling is about scrolling the content as if you are using a touchscreen, so moving the fingers down makes the scroll indicator going up. But while operating scale widgets (as the volume slider) moving the fingers down should move the slider down (since that is what you're virtually grabbing). To me the gtk+ behaviour is the correct one.
It should then be depending on the natural scrolling settings, which would be disabled on a non touch device, like using a scroll wheel. It should he persistent across widgets anyway. No matter which way around.
Can't parse that sorry, would you rephrase?
My use case is a mouse with a scroll wheel. So no natural scrolling there. As expected, gnome-shell decreases volume on mouse down. This is correct behaviour. Let me say it this way: in vlc, scrolling down with the mouse wheel decrases volume/takes you back in the video in gnome-shell scrolling down on the speaker icon decreases volume in totem, scrolling down takes you back in the video and decreases volume only in volume control scrolling down increases volume For the mouse-wheel case, the Volume should surely in any decrease on scrolling down. Every other behaviour is wrong. If any application doesn't reverse this on an input device that has natural scrolling, then that's surely a different problem.
*** Bug 773507 has been marked as a duplicate of this bug. ***
Review of attachment 276171 [details] [review]: Hi Cris, thanks for your patch and sorry for the delay in reviewing it. I agree we should maintain consistency accross the desktop, so I believe this patch is a step in the right direction. However, it does not apply on top of master anymore; would you be so kind to rebase it?
This issue is valid for Gnome 3.28 on Arch Linux.
Created attachment 370521 [details] [review] sound: Invert scroll direction of GvcChannelBar The scrolling mechanism was opposite to that of most other scroll bars. This inverts the scrolling, so scrolling up/right is considered an increasing scroll, and scrolling down/left is considered a decreasing scroll. https://bugzilla.gnome.org/show_bug.cgi?id=703046 Rebased-by: Felipe Borges <felipeborges@gnome.org>
I took the liberty to rebase this patch on top of git master so we can get these changes in. This bug quite annoys me too in my daily interactions with the sound settings.
(In reply to Felipe Borges from comment #14) > I took the liberty to rebase this patch on top of git master so we can get > these changes in. This bug quite annoys me too in my daily interactions with > the sound settings. Could you please move this patch to GitLab, in the form of a MR?
Still valid for Gnome 3.29.91.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.