-------------------------------------------------
Basically, while the usual sequence of events for a multi-click is
- mousedown
- mouseup
- click
- mousedown
- mouseup
- doubleclick
This would of course come at the expense of a delay of a doubleclick timeout interval before an event can be dispatched, which would require it to be an option to be enabled rather than the default behaviour, especially since most situation could avoid this situation by rethinking their interface design (for instance by incorporating a mousedown-before-click and click-before-doubleclick as normal functionality).
The suggestion given saw basically two ways of achieving the goal of cooked event handling in CEGUI, the first involves CEGUI cooking the mouse input into proper events, the second is about the client cooking input and injecting them into CEGUI:
- 1. CEGUI cooks the events:
Enabling setting Windows to dispatch raw or cooked events. Allowing cooked event processing would come at the prise of delayed event dispatching, wherefore this mode would need to be explicitly turned on, alternatively be turned on when a window subscribes to double click events (or the convenience exclusive_doubleclick event that is a shortcut to subscribing to doubleclicks and turning on event cooking?). The precedent for this is the Window::setWantsMultiClickEvents method, which enables a modifier on event handling on a per-Window bases. Thus a corresponding Window::setDelayedEventResoltion (or a name like Window::setCookEvents or Windows::setExclusiveEvents etc) method would be a natural extension. - 2. The client injects events:
Injecting higher-level events into CEGUI: Since CEGUI does not provide input management it is always already up to the client application to inject this into CEGUI. Therefore the client can also perform timing (etc) to determine if single-, double- or tripleclicks have occurred. Currently however, only mouse down and mouse up events can be injected. Therefore System::injectMouseClick, System::injectMouseDoubleClick and System::injectMouseTripleClick [or something like System::injectEvent(MouseEvent::DCLICK)] methods would be required. Here too, the precedent is already set with the System::injectChar method. This is probably the simplest solution to implement in CEGUI.
CE's reply was that he'd prefer the first model to allowing the injection of more event types into CEGUI:
CrazyEddie wrote:Hi,
If we decided to implement such a facility, it's more likely that it will be based upon something closer to your first suggestion than your second; there are no plans to extend the injection interface.
I need to additionally look into various aspects of this for myself, though right at the moment my head is not in the right place, and I'm not feeling too good right at the moment.
Such a change could make it into the 0.7.x series, although I am not promising that. There is going to have to come a point where some additional features are deferred to the following release series, otherwise 0.7.x is never going to see the light of day - and there are already large numbers of large changes that are definitely going into that release, so please understand that all these newer requests get put at the bottom of an already long list.
CE.
Therefore I listed the considerations I needed to make when implementing event cooking in my engine:
Click invalidation checks
- click interval: timeout interval for next down event after the last release event
- release timeout: timeout after the down event after which the click should be removed from the event queue as a click candidate (it might still be a drag)
- Distance threshold: if the mouse has drifted too far during a multi-click event the event should perhaps be discarded
Necessary adjustments and compensations
- drift: the distance from the previous mouse down event position the current mouse down event occurs at in a multi-click event (the first click position should be the proper one)
- divergence: the distance the mouse may travel while the mouse button is held
- target movement: the click target may move before the click interval timeout (I do not handle this (yet), though).
Also, it is worth considering that mutli-tapping is not really limited only to mouse clicks, any digital key could be multi-tapped.