Double-click events

[viridia]

What problem does this solve or what need does it fill?

Multiple users have requested support for double-click events.

What solution would you like?

On desktop platforms, the double click interval is a user preference in the system settings. Unfortunately, this setting is not currently exposed through winit, although it might be possible using platform-specific APIs like windows-sys.

For the short term, we can just go with a fixed constant, perhaps hidden behind an API that would let us migrate to the OS setting in the future.

The other requirement of double-click processing is detecting pointer movement: rapidly clicking on two different places on the screen is not generally considered a double-click. There are a few ways this can be done:

• remembering the coordinates of the previous click, and checking the distance between that and the current click
• detecting whether the click is on the same pickable entity

From an API standpoint, the most straightforward approach would be to add a new field on the Click event. This can be a simple boolean, which if true means that the current click is sufficiently close (both spatially and temporally) to the previous click to be considered a double-click. Triple- and Quadruple-clicks can be handled by a state machine in application code, we don't need to build support for this into Bevy itself.

What alternative(s) have you considered?

An alternative is to have consumers of click events do the double-click detection themselves, although this would most likely lead to inconsistent behavior.

[viridia]

I would also consider that the documentation should give some guidelines on how to process double clicks. The current best practice says that double clicks should be a logical extension of the single click action - it's considered bad practice for the double click to do something that contradicts the single click (necessitating undoing the single click action before processing the double click).

[ickshonpe]

I agree about the design mostly, except I think we should keep things as simple as possible for the Click consumers and have the Click dispatcher track the number of clicks. So rather than a previous_click: bool field, it would be consecutive_clicks_count: u8 or something.

[ickshonpe]

Strongly agree with the doc guidelines comment also. As a concrete example for anyone else about what this means, here on github:

• single-click: sets the cursor position
• double-click: selects the word at the click position
• triple-click: selects the paragraph at the click position.

Code editors can differ, with triple-click selecting a single visual line and quadruple-click selecting the entire file. The common theme being that the new selection must envelop the previous one.

[aevyrie]

For the short term, we can just go with a fixed constant, perhaps hidden behind an API that would let us migrate to the OS setting in the future.

Agree

The other requirement of double-click processing is detecting pointer movement: rapidly clicking on two different places on the screen is not generally considered a double-click

I'm not sure if this is true for accessibility reasons, but I don't have any sources to cite