Bug 442789 - Window actions using mouse wheel inappropriately respect natural scrolling
Summary: Window actions using mouse wheel inappropriately respect natural scrolling
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.21.5
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2021-09-21 22:04 UTC by Roman Odaisky
Modified: 2023-09-29 10:26 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Odaisky 2021-09-21 22:04:18 UTC
SUMMARY


STEPS TO REPRODUCE
1. Enable natural scrolling
2. Go to System Settings > Window Management > Window Behavior > Window Actions > Inner Window, Titlebar and Frame Actions
3. Set mouse wheel action to Maximize/restore

OBSERVED RESULT

To maximize a window, it’s necessary to hold the modifier key and to rotate the mouse wheel towards myself, and away from myself to restore it. This is counter-intuitive.

EXPECTED RESULT

The other way round.
Comment 1 Vlad Zahorodnii 2021-09-22 11:20:27 UTC
> The other way round.
But this defeats the purpose of natural scrolling, doesn't it?
Comment 2 Nate Graham 2021-09-22 18:25:10 UTC
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.
Comment 3 Roman Odaisky 2021-09-23 00:40:58 UTC
(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.
Comment 4 Vlad Zahorodnii 2023-09-29 10:26:33 UTC
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