https://bugs.kde.org/show_bug.cgi?id=442379
--- Comment #8 from Hector Martin <mar...@marcan.st> ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
