Bug 442379

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. ***

(In reply to Adam Fontenot from comment #10)
> 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.

+1 On adding a "natural slider adjustment" option.

I find the new behaviour quite unnatural after using it the way it was for so long. Also since the sliders are perpendicular to the direction of motion, I don't believe there really is a "correct" way for them to respond. Other systems have likely preferred to keep their audio sliders vertical for this same reason. Having separate natural scrolling toggles for content and UI elements seems the most sensible solution.

> I find the new behaviour quite unnatural after using it the way it was for so long.

That sounds like "I got used to the old way even though it didn't make sense", which isn't a terribly good reason not to fix it. :)

> Also since the sliders are perpendicular to the direction of motion, I don't believe there really is a "correct" way for them to respond. Other systems have likely preferred to keep their audio sliders vertical for this same reason.

If you're implying that for a vertical volume slider then "scroll up" on a trackpad should in fact be volume up (i.e. the current behavior after this bug was fixed) *then* it stands to reason that the same should be true for a horizontal slider as, despite there being no "correct" spatial mapping due to the axis being different, the "volume up" metaphor still holds. Indeed, this same rationale applies to non-spatial cases like the Plasma system tray volume icon itself, which simply displays a varying number of "waves". In general, non-scrollbar linear widgets on desktop environments (and, indeed, largely so in the physical world) have always used the "positive right / up" convention, so it stands to reason that they would be mapped this way.

That said, I just noticed that horizontal sliders and indeed the tray icon itself *also* respond to horizontal trackpad movement, which is also excellent as it matches the direction of the slider.

As I said in my earlier comment, the only reason we ended up in this mess to begin with is because scroll wheels were *specifically* intended for the use case of viewport scrolling first (which is inverted vs. the content), then widgets have always tried to use "natural scrolling" by inverting the scroll direction at the widget level, and then finally "natural scrolling" for trackpads was originally implemented as a hack that inverted all scrolling regardless of scroll target, making the widgets move backwards unintentionally. People might have gotten used to that, but I really doubt there is a strong argument to be made that this behavior is, in any way, intuitive.

Yep, Hector's view is pretty much the one shared by the dev team here. I know it can be annoying to get used to new things when something abruptly reversed behavior, but when the old thing was conceptually wrong in the first place, IMO it's worth investing some brainpower into adapting. :)

Is this really fixed? I'm still seeing this issue in:

Operating System: openSUSE Tumbleweed 20240815
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.10.4-1-default (64-bit)
Graphics Platform: X11

Only on Wayland; it's unfortunately not feasible to fix on X11.