SUMMARY Interacting with widgets in the panel do not follow the users preference for Inverted Scroll Direction/Natural Scrolling. For example: Scrolling the volume widget from the panel. This applies not only to just scrolling on the widget icon to change volume, but also the sliders within the widgets themselves. The following are affected: - Scrolling the Volume Icon - Scrolling the Volume Widget view sliders - Scrolling the Brightness Widget view sliders - Scrolling the Power Management view sliders Unaffected: - Notification widget view STEPS TO REPRODUCE 1. Open System Settings and go to Input & Output > Mouse & Touchpad > Mouse. 2. Under Scrolling, toggle Invert Scroll Direction on and click Apply. 3. Ensure the volume widget is added to your panel. 4. Test by scrolling the volume widget icon or its sliders on the panel. 5. Observe the scroll direction is not inverted per the user preferences. OBSERVED RESULT The scroll direction for the volume widget and its sliders remains unchanged, not reflecting the Invert Scroll Direction preference. EXPECTED RESULT The scroll direction for the volume widget, as well as the sliders in the widget, should follow the user’s Invert Scroll Direction preference, i.e., scrolling should be inverted (natural scrolling). SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6900 XT
I was able to reproduce this on gitlab master (as of today), hence keeping Version as it is. For additional context, I'm unsure if there was a time I can remember the widgets acting differently or if this has always been the case, but I remember being able to follow the same steps to reproduce this in Plasma 5 back in the day too.
As far as I am aware this is intentional: Scrolling up should always raise the volume, scrolling down always lower. Same for brightness up = > brighter
(In reply to David Redondo from comment #2) > As far as I am aware this is intentional: > Scrolling up should always raise the volume, scrolling down always lower. > Same for brightness up = > brighter Cheers David. Just to double check, even though the user has set their mouse scroll to inverted, you're certain this behaviour is intentional and the widgets are designed to ignore that setting? From a user’s perspective, I could just change the setting in the mouse preferences back to normal and not use the inverted option if I preferred the normal scroll directions, but it is somewhat disorienting being the only place that does not follow the user preference. I'm just trying to understand the reasoning behind this intentional decision? I'm would be happy to reopen this as a feature request, but I obviously don't want to waste anyone's time if it's definitely intended.
> you're certain this behaviour is intentional and the widgets are designed to ignore that setting Yes, there's extra code added to handle it specifically due to users complaining .. >I'm just trying to understand the reasoning behind this intentional decision? Rationale is the setting on whether scrolling moves in the direction of the contents or the direction of the scrollbar. This isn't about scrolling it just happens to use the wheel.
(In reply to David Edmundson from comment #4) > > you're certain this behaviour is intentional and the widgets are designed to ignore that setting > > Yes, there's extra code added to handle it specifically due to users > complaining .. > > >I'm just trying to understand the reasoning behind this intentional decision? > > Rationale is the setting on whether scrolling moves in the direction of the > contents or the direction of the scrollbar. This isn't about scrolling it > just happens to use the wheel. Thanks for the explanation, David, appreciate it! The rationale is much clearer now, and hopefully, this will help others who might be confused about that functionality if they come across this report in the future. Thanks again!