Skip to content
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

More advanced click handling… #640

Open
bwinton opened this issue Jul 25, 2020 · 4 comments
Open

More advanced click handling… #640

bwinton opened this issue Jul 25, 2020 · 4 comments
Labels
enhance-feature Create a new user-facing feature subsystem-input

Comments

@bwinton
Copy link

bwinton commented Jul 25, 2020

Describe the problem you want to solve
So, I've got my code running on a web page, and it's great from a desktop computer, but on my phone it's much harder to type into a web page, so I'm hoping to use double-click for the secondary function, but that will involve a lot of code on my part. Also, when I click to scroll the page around, the click gets passed into my event handler, which I'd rather it wasn't.

Describe the solution you'd like
A new (perhaps opt-in for performance reasons) api for double-clicks would be nice, as would filtering out touches that are used to pan and zoom on mobile devices.

Are you interested in contributing?
I'd (still) love to, but lack of time doesn't allow me to more than offering the occasional suggestion.

@ryanisaacg ryanisaacg added enhance-feature Create a new user-facing feature subsystem-input labels Jul 26, 2020
@ryanisaacg
Copy link
Owner

Currently mobile support isn't really in scope, I'm sorry to say. To do it well would require significant design and development work, which I don't think I can take on.

@bwinton
Copy link
Author

bwinton commented Jul 26, 2020

Yeah, that's understandable. How about double-clicks? :)

@lenscas
Copy link
Contributor

lenscas commented Jul 26, 2020

how do you want quicksilver to handle them?

If it is done like any other event, then should the first click still be registered as a click, or should that even be fired as normal? What about the second? Should that only cause the "double click" event or also the normal click event?

Or do you rather have a seperate struct that you configure with the maximum time between clicks and has a method that takes a reference to the click event and tells you whether it is a double click?

If the separate struct is good enough then I can probably open a pull request in a few days. Just want to know if that is useful, if it would be accepted, etc, etc before I start working on it.

@bwinton
Copy link
Author

bwinton commented Jul 26, 2020

I would be happy with any of the things you suggested, but I suspect people writing games wouldn't want the first click to be paused for an arbitrary amount of time, so perhaps the first click should fire as normal, and then the second would fire as a double-click event (along with another normal click event, for backwards compatibility)?

I'm a little hesitant to suggest we follow what JavaScript does 😉, but the MDN page says:

The MouseEvent object passed into the event handler for click has its detail property set to the number of times the target was clicked. In other words, detail will be 2 for a double-click, 3 for triple-click, and so forth. This counter resets after a short interval without any clicks occurring; the specifics of how long that interval is may vary from browser to browser and across platforms. The interval is also likely to be affected by user preferences; for example, accessibility options may extend this interval to make it easier to perform multiple clicks with adaptive interfaces.

which seems reasonable to my not-particularly-advanced eyes…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhance-feature Create a new user-facing feature subsystem-input
Projects
None yet
Development

No branches or pull requests

3 participants