qt: assume touchpad wheel events are inverted if invertedness is not reported
WheelToVLCConverter
is not used for scrolling, so we have to handle inversion.
This was already done in 1ba2a2db (!6610 (merged)), but unfortunately not all platform (plugins)
report invertedness.
According to my knowledge, Mac and Wayland platform plugins report, while Xcb and Windows/Direct2D do not report.
Usually touchpad scrolling direction is inverted, which may be the source of events in this class, so it makes more sense to assume the wheel events are inverted by default.
Request review @chub.
Merge request reports
Activity
added 1 commit
- 20d84013 - qt: forward the remaining of `QQuickWheelEvent` properties in `WheelToVLCConverter`
added MRStatus::Reviewable label
Although this works fine on X11, it is still not enough for Windows because device type is reported as
QInputDevice::DeviceType::Mouse
in my case on Windows 11 with precision touchpad.I'm not sure what can be done, maybe for Windows we need to invert all fractional events (angle delta not multiple of
120
). The concern with that is non-standard mouse that provide fractional delta for wheel events and not inverted by default.According to https://github.com/qt/qtbase/blob/a5f80b4732d33dd36414a6ffbd49a9efc7c87a0a/src/plugins/platforms/windows/qwindowspointerhandler.cpp#L67, Qt does not handle touch pad (pointer) messages, so I assume that Windows sends a mouse wheel message afterward because of that.
I'm not sure how much it makes sense to handle pointer messages ourselves in the application specifically for Windows. I would rather invert all events where delta is high precision / fractional on Windows, what do you think @chub?
On windows, there are indeed two types of messages for mouse events:
- QtWindows::NonClientMouseEvent
- QtWindows::NonClientPointerEvent
handled here respectively by
translateMouseEvent
andtranslatePointerEvent
Mouse events are indeed reported as never inverted (wheel event use the default inverted value, which is false)
- https://github.com/qt/qtbase/blob/6.8.1/src/plugins/platforms/windows/qwindowspointerhandler.cpp#L739
- https://github.com/qt/qtbase/blob/6.8.1/src/gui/kernel/qwindowsysteminterface.h#L96
are inverted if invertedness is not reported
are you sure it needs to be inverted? the touchpad seems to behave the same way as windows other applications (both the volume and list/grid scrolling) As far as I know, there is no way to invert scroll direction from Windows settings
note on XCB, mouse direction is not reported as well (here), but I see no issue with this, the current behavior is the same across application (both how volume and flickables are handled)
Note that Kde on X11 allows to invert the scroll direction on both touch and mouse, which gives the expected behaviors
It looks like your assumptions on what should be inverted is inverted ;-)
are you sure it needs to be inverted?
It needs to be inverted, because it is inverted by default due to natural scrolling, and here we don't intend to use it for scrolling.
the touchpad seems to behave the same way as windows other applications (both the volume and list/grid scrolling)
I think that is because most applications do not handle pointer events, but rather rely on mouse wheel events. That does not necessarily mean that we should do the same.
the current behavior is the same across application (both how volume and flickables are handled)
In flickable case, it is scrolling but in this case it should not be considered scrolling so we should in my opinion invert if the event is inverted.
"Scrolling" down to increase volume or left to seek forward is really counter-intuitive in my opinion.
As far as I know, there is no way to invert scroll direction from Windows settings
On Windows 11, at least with precision touchpad, there is a setting to change the direction. The default is inverted (first entry). Note how it is not advertised as "inverted".
note on XCB, mouse direction is not reported as well
In my case it is reported, have you seen the check above (https://github.com/qt/qtbase/blob/a10acaca0887541207ad5607680d7864d317cf4b/src/plugins/platforms/xcb/qxcbwindow.cpp#L1954)
connection()->isAtLeastXI21()
, maybe it is about that?but I see no issue with this, the current behavior is the same across application (both how volume and flickables are handled
This is really not good in my opinion, in flickable case it is scrolling, but it is not scrolling for volume.
Note that Kde on X11 allows to invert the scroll direction on both touch and mouse, which gives the expected behaviors
That is usually advertised as "Natural Scrolling" on Linux. I'm not sure if it comes on by default but as the name suggests it is rather for scrolling (not for adjust the sliders, for example).
In my case it is reported, have you seen the check above
I mean the device here, not invertedness (that is why windows and xcb are blacklisted in this merge request as they don't report invertedness). This makes it possible to assume that if the device is touchpad, it is inverted by default if invertedness is not reported.
"Scrolling" down to increase volume or left to seek forward is really counter-intuitive in my opinion
that's people choice, other volume widgets in other applications will behave this way. If we're the only application that doesn't respect the user choice this will be very annoying. note that in VLC, wheel direction in detached windows do behave like this too
In my case it is reported, have you seen the check above (https://github.com/qt/qtbase/blob/a10acaca0887541207ad5607680d7864d317cf4b/src/plugins/platforms/xcb/qxcbwindow.cpp#L1954)
connection()->isAtLeastXI21()
, maybe it is about that?With XInput2 wheel event is handled here but direction is not provided as well, I think it's changed on server side
that's people choice
I can't agree with that, both as a user and a developer.
The setting is advertised for scrolling. Adjusting the volume is not scrolling, so it should always "scrolling" up increase the volume and vice versa.
The people choice is for scrolling and I agree that we should respect it, that's why I opened !6665 (merged).
changed milestone to %4.0
added Component::Interface: Qt label
added MRStatus::InReview label and removed MRStatus::Reviewable label
mentioned in merge request !6665 (merged)