Bug 473125 - Switching between System Settings pages with a stylus doesn't work most of the time in Plasma 6
Summary: Switching between System Settings pages with a stylus doesn't work most of th...
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: sidebarview (show other bugs)
Version: master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: qt6
Depends on:
Blocks:
 
Reported: 2023-08-08 00:03 UTC by guimarcalsilva
Modified: 2023-10-17 14:25 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0
Sentry Crash Report:


Attachments
System settings refuses click from a stylus most of the time - Other apps like Dolphin are unaffected (1.93 MB, video/x-matroska)
2023-08-08 00:03 UTC, guimarcalsilva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description guimarcalsilva 2023-08-08 00:03:41 UTC
Created attachment 160818 [details]
System settings refuses click from a stylus most of the time - Other apps like Dolphin are unaffected

SUMMARY
Clicks on System Settings are not registered most of the time when using a Stylus in Plasma 6. Switching categories with a stylus works in Plasma 5 (though there's another related bug that affects Plasma 5 and 6 - I'll report it shortly). Clicking changes the highlight color of the menu item but it doesn't actually switch to a new page most of the time. Check the attached video for more details.

STEPS TO REPRODUCE
1. Use a Stylus with a drawing tablet (not a finger)
2. Open System Settings and try to click on the menus by touching the stylus on the drawing tablet

OBSERVED RESULT
It looks like it selects the list item but it doesn't actually click most of the time. You have to click many times to register a click

EXPECTED RESULT
Touching the stylus on the drawing tablet should be registered as a click, like in all other apps

SOFTWARE/OS VERSIONS
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.27.80
KDE Frameworks Version: 5.240.0
Qt Version: 6.6.0
Kernel Version: 5.19.0-50-generic (64-bit)
Graphics Platform: Wayland
Processors: 6 × Intel® Core™ i5-9400F CPU @ 2.90GHz
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 570 Series

ADDITIONAL INFORMATION
Tested on a Live session
Comment 1 Nate Graham 2023-08-09 18:08:34 UTC
Can reproduce.
Comment 2 Fushan Wen 2023-09-30 14:28:35 UTC
Fixed in Qt 6.5.3

https://bugreports.qt.io/browse/QTBUG-114258
Comment 3 Nate Graham 2023-10-17 14:24:06 UTC
Git commit 70678e79c908ce03cf996f2317fdac2ee0c3eb03 by Nate Graham, on behalf of Aki Sakurai.
Committed on 17/10/2023 at 16:24.
Pushed by ngraham into branch 'master'.

Correct the misgenerated localMouseEvent

This commit fixes the issue where some parts of Qt6 widgets couldn't 
be clicked with a Wacom tablet stylus.

1. QMouseEvent is constructed with incorrect arguments.
https://doc.qt.io/qt-6/qmouseevent.html#QMouseEvent-3

The _button_ that caused the event is given as a value from the 
Qt::MouseButton enum. If the event _type_ is  MouseMove, then
the appropriate button for this event is Qt::NoButton. _buttons_
is the state of all buttons at the time of the event, _modifiers_
is the state of all keyboard modifiers.

2. Some parts of Qt widgets require a timestamp to function properly.
https://codereview.qt-project.org/c/qt/qtdeclarative/+/493020

QQuickWidget: give each mapped mouse event the same QEventPoint.
Counter-intuitively, this is done by setting the timestamp. Every
time you construct a new mouse event, you always need to call
setTimestamp() for the obvious reason: the timestamp is not a ctor
argument, but it's important for some event receivers. But the
non-obvious reason is that QMutableEventPoint::setTimestamp() has
other useful side effects: the velocity calculation is done there,
sensibly enough. But to make that possible, it also looks up the
persistent QEventPoint with the same ID as the one in the QMouseEvent,
and that's the most important to fix QTBUG-114258 specifically. QQuickFlickablePrivate::handleMoveEvent() calculates delta as
QEventPoint::position() - mapFromGlobal(globalPressPosition()) and
then QQuickFlickablePrivate::drag() does the drag threshold check.

M  +3    -1    kstyle/oxygenwindowmanager.cpp

https://invent.kde.org/plasma/oxygen/-/commit/70678e79c908ce03cf996f2317fdac2ee0c3eb03
Comment 4 Nate Graham 2023-10-17 14:24:22 UTC
Git commit b050ab3bca5a667fcea8137f74f8eea514d57f0f by Nate Graham, on behalf of Aki Sakurai.
Committed on 17/10/2023 at 16:24.
Pushed by ngraham into branch 'master'.

Correct the misgenerated localMouseEvent

This commit fixes the issue where some parts of Qt6 widgets couldn't 
be clicked with a Wacom tablet stylus.

1. QMouseEvent is constructed with incorrect arguments.
https://doc.qt.io/qt-6/qmouseevent.html#QMouseEvent-3

The _button_ that caused the event is given as a value from the 
Qt::MouseButton enum. If the event _type_ is  MouseMove, then
the appropriate button for this event is Qt::NoButton. _buttons_
is the state of all buttons at the time of the event, _modifiers_
is the state of all keyboard modifiers.

2. Some parts of Qt widgets require a timestamp to function properly.
https://codereview.qt-project.org/c/qt/qtdeclarative/+/493020

QQuickWidget: give each mapped mouse event the same QEventPoint.
Counter-intuitively, this is done by setting the timestamp. Every
time you construct a new mouse event, you always need to call
setTimestamp() for the obvious reason: the timestamp is not a ctor
argument, but it's important for some event receivers. But the
non-obvious reason is that QMutableEventPoint::setTimestamp() has
other useful side effects: the velocity calculation is done there,
sensibly enough. But to make that possible, it also looks up the
persistent QEventPoint with the same ID as the one in the QMouseEvent,
and that's the most important to fix QTBUG-114258 specifically. QQuickFlickablePrivate::handleMoveEvent() calculates delta as
QEventPoint::position() - mapFromGlobal(globalPressPosition()) and
then QQuickFlickablePrivate::drag() does the drag threshold check.

M  +2    -1    kstyle/breezewindowmanager.cpp

https://invent.kde.org/plasma/breeze/-/commit/b050ab3bca5a667fcea8137f74f8eea514d57f0f