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.