Can confirm when using natural scrolling. Does it work properly for you when *not* using natural scrolling?

(In reply to Nate Graham from comment #1)
> Can confirm when using natural scrolling. Does it work properly for you when
> *not* using natural scrolling?

yes, when I do not use natural scrolling it is fine.

Thanks.

Qt does have a property on the wheel event to signify if it's inverted or not

(In reply to David Edmundson from comment #4)
> Qt does have a property on the wheel event to signify if it's inverted or not

I just had a look at that, I figured this would be an easy fix with something like
> if (wheel.inverted) wheelDelta = -wheelDelta
but as it turns out the "inverted" property of the WheelEvent always returns false even if the scrolling direction is actually inverted, both on X11 and Wayland, and both with a touchpad and with a mouse.

The Qt docs themselves even say
> Note: Many platforms provide no such information. On such platforms inverted always returns false.
https://doc.qt.io/qt-5/qml-qtquick-wheelevent.html#inverted-prop

So I guess it's not as easy to fix as it seemed.

(In reply to kdebugzilla from comment #0)
> When I scroll with the touchpad on the audio icon to adjust the volume, I
> have to scroll up to lower the volume and scroll down to increase it; I
> think that this doesn't make sense and these two bindings should be inverted.

As a user of natural/inverted scrolling for years, I would argue that this is not actually a bug, but working as expected.  "Invert scrolling" means invert it _everywhere_, including the volume applet. 
It also makes more sense if you picture a vertical volume slider (with 100% volume at the top) with a handle that works the same as any other scroll bar: you do scrollwheel-UP to push that handle down (i.e. lower volume) and vice versa.

See also #442789, since this issue affects basically all non-scroll window actions as far as I can tell (sliders, etc).

(In reply to paul from comment #6)
> As a user of natural/inverted scrolling for years, I would argue that this
> is not actually a bug, but working as expected.  "Invert scrolling" means
> invert it _everywhere_, including the volume applet. 
> It also makes more sense if you picture a vertical volume slider (with 100%
> volume at the top) with a handle that works the same as any other scroll
> bar: you do scrollwheel-UP to push that handle down (i.e. lower volume) and
> vice versa.

It makes no sense on a touchpad. "Natural scrolling" on a touchpad means you drag window content in the direction you want it to go. That happens to be the opposite of the old default for scrolling windows, but not for sliders and volume controls. Right now, enabling natural scrolling means you scroll down to turn the volume up, which makes no sense. There is no "wheel" metaphor to make an inverted direction ever make sense like there is on a mouse.

Ultimately, the root cause of all this confusion is that when people first defined wheel scrolling for window content, they did so based on *viewport/scrollbar movement* ("scroll down" means "look down" which means "move the content up"). But that is not the case for any other context in which the scroll wheel is used, where down and up are directly mapped. "Invert scrolling" and "Natural scrolling" are therefore not, really, the same concept. "Invert" might be expected to "invert everything" under some interpretations, but there is nothing natural about that. What people naturally expect from "Natural scrolling" is that window content scrolling flips from viewport-centric to content-centric, and nothing else.

Fixed by Vlad Zahorodnii with https://invent.kde.org/plasma/plasma-pa/-/commit/4578f4fef52bac4f87aad2fc148c2d9a6e191be2 in Plasma 6.0!

I want to add that I strongly agree with @paul, above, that it is the *new* behavior that is unexpected and unintuitive.

I argue that most users who select "natural" or reversed scrolling on a touchpad want reversed scrolling everywhere, not to have their settings second guessed by KDE and overridden on desktop applets (but seemingly nowhere else).

This seemed so obvious to me that I filed a bug about the new behavior: https://bugs.kde.org/show_bug.cgi?id=478146

I'd really like to see this reconsidered or at least an option to turn it off and respect the reversed-scrolling setting. I think the decision to change this happened too quickly, probably without much input from users who use natural scrolling regularly.

*** Bug 479028 has been marked as a duplicate of this bug. ***