SUMMARY Natural scrolling setting doesn't affect Window List widget STEPS TO REPRODUCE 1. Add some windows. 2. Disable natural scrolling feature. OBSERVED RESULT The widget uses natural scrolling. EXPECTED RESULT The widget should not use natural scrolling when it is disabled. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Kernel Version: 6.10.10-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz Memory: 15.3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1650/PCIe/SSE2
BTW, there is the same problem in overview mode (Meta + W)
Can you clarify what exactly you are scrolling over in these cases? Is it a view with a scrollbar? Or something else?
I tried reproducing with the window list applet, with enough windows so that the popup menu requires scrolling. Seems to respond correctly to switching inverted scroll direction, both on a mouse-type device (pointing stick) and a touch pad, even with switching back and forth between them multiple times. (With the touchpad, I sometimes couldn't scroll all the way up, but that might be my low skills at using touchpads) I couldn't find anything that allows scrolling in the overview.
Created attachment 174023 [details] Window list widget I swipe to the left. Nothing changes with the setting
Ah, that's not Window List. Window List is a popup menu that shows all open windows. What you're showing in the video is called the Pager widget. I still can't reproduce it on master though - both up/down and left/right scrolling on the Pager get flipped when I select that option in the Touchpad configuration. The computer where I have my Fedora VM is not accessible right now, so I can't test that.
I can sort of reproduce the issue. The scroll directionality definitely changes when I toggle natural scrolling on and off, but I think the behaviors are flipped: with natural scrolling turned on, scrolling up navigates down, while with natural scrolling off, scrolling up navigates up. That seems actionable to fix.
I see: it's correct with a scroll wheel, but inverted from the expected behavior with a touchpad.
(In reply to Nate Graham from comment #6) > I can sort of reproduce the issue. The scroll directionality definitely > changes when I toggle natural scrolling on and off, but I think the > behaviors are flipped: with natural scrolling turned on, scrolling up > navigates down, while with natural scrolling off, scrolling up navigates up. Hm, I'm not sure what you mean. When I'm on the first desktop (single line horizontally on this computer), scrolling down with natural scrolling off scrolls me to workspace 2, which seems correct. Similarly if I change to a vertical line, scrolling down scrolls me down. This is also how e.g. comboboxes behave with natural scrolling off - scroll down to get to the next item down in the list. This happens with both touchpad and pointing stick (which uses the mouse kcm). I'll admit that flipping this doesn't seem very 'natural', but it is the "inverted scroll direction". Given that there isn't an actual view being moved, only the position, I could see not having scrolling direction affect this at all - scrolling direction is also not inverted when scrolling over sliders, that wouldn't make sense. But changing the scrolling direction here for non-natural scrolling seems like it might be ... controversial.
I think it's easiest to reproduce with a vertical list of desktops in a vertical pager. With a horizontal one, the directionality becomes confusing IMO. This could also be one of those cases where taking into account inversion status doesn't make sense.
(In reply to Nate Graham from comment #7) > I see: it's correct with a scroll wheel, but inverted from the expected > behavior with a touchpad. which is a problem as is not that feasible to tell them apart in code
I thought we could on Wayland.
Is Bug 483601 the same thing, or something subtly different? I can't tell.