| Summary: | "Drag start distance" configuration option missing when using Libinput | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Matthias Mueller <mat.mueller> |
| Component: | kcm_accessibility | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | anonkun, bugs5.kde.org, nate, plasma-bugs, raghu, s_chriscollins, unassigned-bugs |
| Priority: | NOR | ||
| Version: | 5.16.3 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| URL: | https://bugreports.qt.io/browse/QTBUG-57849 | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=402376 https://bugs.kde.org/show_bug.cgi?id=374311 |
||
| Latest Commit: | Version Fixed In: | ||
|
Description
Matthias Mueller
2019-08-01 18:15:20 UTC
Let's use this to track just the issue of "drag start distance" being missing. *** Bug 387459 has been marked as a duplicate of this bug. *** *** Bug 410236 has been marked as a duplicate of this bug. *** *** Bug 374311 has been marked as a duplicate of this bug. *** UI-wise, one issue here is that this isn't just a mouse setting; it affects touchpad right-clicking too. So it wouldn't really be appropriate to put it in either the mouse KCM or the touchpad KCM. If we had a combined Mouse & Touchpad KCM like GNOME has, then we could use that to locate options that affect both mice and touchpads, like the "Drag start distance" setting as well as the single-click/double-click setting that got moved to Workspace Behavior a year or so ago. As this won't be too many configuration options (if i understood correct?), i see no issue in adding them to workspace behaviour. One thing to consider might be hiding these options in workspace behaviour when evdev is used though. Nate, re-adding the missing configuration for the time/distance values won't fix the Qt bug of not respecting them in the first place. True enough, but without a user-visible setting, once the Qt issue is fixed, we'll still need some way for people to twiddle with it, right? Should https://bugreports.qt.io/browse/QTBUG-57849 be renamed? Has this been solved upstream? It doesn't happen anymore on my freshly reinstalled and updated KDE Neon. @Mark Smith No the upstream bug is not solved yet and I can still reproduce this on plasma 5.20.1 on arch Moving to the accessibility KCM, since that's where the other click-related tweaks now live, and there is no logical reason to put this in the mouse settings since it's not a mouse-specific setting (it affects touchpads too). (In reply to Raghavendra kamath from comment #10) > @Mark Smith No the upstream bug is not solved yet and I can still reproduce > this on plasma 5.20.1 on arch I know for sure this doesn't happen anymore on Operating System: KDE neon 5.20 KDE Plasma Version: 5.20.1 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.0 Kernel Version: 5.4.0-52-generic It still happens in certain apps such as Firefox. But in every KDE app it doesn't happen anymore. Insert confused face emoji here. For me it happens in krita and the problem is more highlighted when you use a graphic tablet where your cursor won't be as static as the mouse. In krita right clicking on a layer would instantly trigger a miss click and activate the first context menu item. > doesn't happen anymore on
> Qt Version: 5.15.0
There is a regression in Qt 5.15.0 that prevents the down-move-up menu selection to no longer work, you need to use down-up-move-down-up. This is fixed in Qt 5.15.1, so if you update Qt, then you will see QTBUG-57849 bug again.
|