| Summary: | Window actions using mouse wheel inappropriately respect natural scrolling | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Roman Odaisky <to.roma.from.kdebug> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | minor | CC: | bugseforuns, m.kurz, nate |
| Priority: | NOR | Keywords: | usability |
| Version: | 5.21.5 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=442379 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Roman Odaisky
2021-09-21 22:04:18 UTC
> The other way round.
But this defeats the purpose of natural scrolling, doesn't it?
No, natural scrolling makes sense for page content (according to the people who use it, at least), but it doesn't make sense in other contexts. For example it doesn't make sense for scrolling *up* over the Audio Volume applet to make the volume go *down* (Bug 442379). There is apparently a property you can use to query whether or not the direction is invert it and ignore the inversion, for precisely this use case. (In reply to Vlad Zahorodnii from comment #1) > > The other way round. > But this defeats the purpose of natural scrolling, doesn't it? The point of natural scrolling is for objects on the screen to move in the same direction as the user’s finger. In my mind, I’ve always associated maximization with movement towards the top, that’s why the current motion of the mouse wheel seems inconsistent to me. However, on second thought, maximization might be perceived as pulling the window towards yourself in imaginary 3D space, in which case the current motion is just right. It looks like a UI control to specify one or the other mapping between wheel rotation direction and the action triggered should be the way to go and very much in the spirit of KDE. Git commit 4b1a90b32a0b8a2f054d5c4d6dce52b3176d5d86 by Vlad Zahorodnii, on behalf of David Edmundson. Committed on 29/09/2023 at 12:18. Pushed by vladz into branch 'master'. Implement axis relative direction This is useful for the few cases where wheel events are not for scrolling. For example adjusting the volume in the tray. In this case having the metadata that the delta is backwards is important. From a kwin POV it's just proxying the libinput isNaturalScroll setting to clients. Tested against "qtbase/examples/widgets/widgets/mousebuttons" with modified Qt and changing the setting in the UI. Not mergable until upstream lands. Relevant link: https://gitlab.freedesktop.org/whot/wayland/-/merge_requests/1 / https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/183 M +1 -1 src/backends/libinput/device.h M +5 -0 src/core/inputdevice.cpp M +2 -0 src/core/inputdevice.h M +4 -2 src/input.cpp M +2 -1 src/input_event.cpp M +6 -1 src/wayland/pointer.cpp M +2 -1 src/wayland/pointer.h M +3 -3 src/wayland/seat.cpp M +9 -1 src/wayland/seat.h https://invent.kde.org/plasma/kwin/-/commit/4b1a90b32a0b8a2f054d5c4d6dce52b3176d5d86 |