-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Selecting objects using a graphics tablet is difficult (requires zero movement) #1981
Comments
Yes, iD uses a different system for clicking (see #530 ). Since a click in iD can immediately be followed by a drag motion, it's a higher priority to make sure accidental displacement doesn't occur than to detect every possible click. |
OK - so, does this mean that my issue could be fixed simply by upping (In firefox I know how to use the inspector to live-hack CSS; if I could see a way of doing this with the JS I'd try it right now. If you happen to know a simple way I can test such tweaks without major setup that'd be handy...) |
Hmm, I'm not sure this can be accounted for by the filtering that I thought it might be due to the click-canceling behavior of drag but that seems to actually be dead code. In my tests I simply don't see any click events dispatched by the browser when dragging vertices or points. |
Does this happen equally for all feature types (points, vertices, lines, areas)? |
Trying this out again, I realise that I don't think wiggle-tolerance is actually what's causing my issue:
This suggests to me that clicks originating from the graphics-tablet lead to a different series of events received, than clicks from the touchpad. Other clicks (such as clicking the zoom + or -) work perfectly fluidly with my graphics-tablet. I would be inclined to blame the graphics-tablet driver, but it's the most common brand (Wacom Bamboo, mine is CTL-470) and it works fine in absolutely everything else. (I use it with josm often.) If anyone is able to test with a graphics tablet and see if there's a clear difference in the events received, that would help. Or if there's a way I can dump such events during my session. |
@jfirebaugh yes, it occurs for all 4 feature types. |
A lot's changed in six and a half years! We now have pointer events (#5505) and can thus treat stylus and mouse interaction differently. I don't have a graphics tablet but selecting nodes without dragging them using an Apple Pencil on iPad was near-impossible, as described. I added a higher pixel tolerance for styluses which solved the issue. Selecting ways and areas appears to be unproblematic, so whatever changed about that behavior in the long interim must have already fixed the issue. |
Selecting objects in iD appears to require exactly zero movement of the cursor at the moment of clicking. This becomes evident when you try it with a graphics tablet plugged in, when it becomes very difficult to select anything!
This lack of tolerance for clicking is different to the behaviour of everything else within the web browser. For example I can click normal links (like the "History" link) in a fluid pass without ever stopping still.
I presume that you're not using the standard web browser's "onClick" behaviour, but some kind of internal "onMouseDown/onMouseUp" logic? If so, please could you add a small tolerance for slight movement during clicking?
(I'd like to remark that this is not just an issue of convenience, but of interface consistency and accessibility.)
The text was updated successfully, but these errors were encountered: