End-user problem: a single mouse click is interpreted as the start of dragging instead, on Mac
-
Hi. I'm not a desktop programmer, but I have the same glitch occurring in two apps built on Qt, and I wonder if there's anything I can do as a user to fix it. The apps are QGIS (Qt 5.12.3) and KeePassXC (Qt 5.15.0), the OS is MacOS (10.13). The problem is that sometimes, when I click the left mouse button (and release it), the app thinks the button is still being held down, so subsequent cursor movement turns into mouse-dragging, and the original click doesn't work as intended—I have to click another time to ‘finish’ dragging and then redo what I was trying to do.
KeePassXC has this occasionally happen on buttons in options dialogs, in which I don't delve that much: the UI buttons stay pressed after I release the mouse. But the issue is especially pronounced in QGIS, happening every few clicks on the map. Since it's a map-editing app, it involves a lot of mousework, which consists almost entirely of left-clicks, whereas dragging is used only to select multiple points on the map. So every time I click on an object, I have to check if I'm now dragging instead, and if so then I need to click again to shake off this selection—and this click may also be interpreted as a start of another selection.
This doesn't happen in other apps that I use regularly, which are all non-Qt apps—that's why I think the issue might be on Qt's side. However, I checked now in Anki (Qt 5.14.2) and VirtualBox (Qt 5.6.3) by clicking around, and don't see this happening, though that doesn't conclusively exclude the possibility.
Has this issue happened to anyone else? Judging by the persistence of the problem through multiple updates of the apps, it's not known to their developers. My attempts at web search uncovered only this post about the same behavior in VirtualBox and Nixnote2, also on Qt, but this time on Linux.
I haven't noticed any system as to when this happens: all the time in QGIS, sporadically in KeePassXC. One thing that might be relevant is that I'm using an underpowered machine, and tend to click and move the mouse rather fast in QGIS (but I'm definitely not dragging the mouse by accident, by now). Since QGIS is rather heavy, it might process clicks with a bit of a delay—though imho that still shouldn't affect input so severely, as it's the job of a framework to deliver discrete events as they occurred. I'm guessing it might be a factor that the map is not a standard desktop UI element.
(Sorry if this is a wrong place to post such things. Let me know if that's the case.)
-
Hi and welcome to devnet,
Did you check the Qt version used by these applications ?
Updating it could fix the problem. -
@SGaist Not yet, I hoped (and still do) that someone knows something about this particular issue. Should've guessed that I ought to try building them with fresh Qt, though. QGIS is pretty heavy and complex, so building it on my machine and with my luck will take quite a bit of time and likely a number of bumps—in the meantime, I'll keep hoping.
-
Are you able to provide a minimal complies le example that shows that behaviour ?
-
@SGaist Alas no, I'm coming here as an end-user not really familiar with desktop programming. I understand that Qt doesn't normally deal with end users, and I would post the issue in the QGIS tracker instead but the sight of over 3000 open tickets told me I'm probably out of luck there.
If nothing else helps, I might be somewhat able to fiddle with the code and try extracting the map component of QGIS to see what's wrong with it, but the app is pretty complex so I'm now in the ‘kicking the tires’ stage and looking to avoid more-involved approaches.
-
@J-Hilk That's interesting info, thanks. I'm using an external mouse, but the machine is indeed a Macbook with the trackpad set to clicking on a tap—so I guess it might be possible that Qt processes some low-level events in a weird way.
However, while I tried changing the system settings it turned out my MacOS forgot that it has a trackpad at all, and doesn't show those options even though input works fine. I don't think this new problem of mine is related to dragging-on-click since dragging-on-click is older IIRC (and occurs on Linux too, judging from the link)—but apparently I will now be fighting MacOS instead for a while, as quick googling didn't uncover anything on this topic. I also thought that I already checked if dragging-on-click persists with all input-tuning apps turned off, but perhaps I misremembered. Will report after I wrangle the OS and make it behave properly.
