Resolving order of events - single and double clicks

[Mikademus]

Heh, interface-related questions are always interesting according to me, at least.

CE, if I knew the CEGUI framework I'd happily pitch in and try different solutions myself, but I'm afraid it would take quite some effort to get to the point that I'd be able to contribute anything worthwhile...

[Mikademus]

Ok, having thought about this for some time I have some ideas --or rather notions-- I want do discuss.

As I see it atm there are basically two ways of achieving the goal of cooked even 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.

[Speedo]

It seems to me that the best (only?) solution here is to make the single click action benign enough that when the single click event occurs you can always go ahead and process it without caring whether or not it's going to be followed by a double click event. While you *could* work in some delays in event dispatching to try and distinguish the events, I expect that you'll get a lot of user complaints about it. UI "lag" is one of those things that people tend to almost universally hate.

With what you said you want, I think you're already fine in that area. If the user double clicks to focus on an object, then it's not terribly illogical to assume that they will want that unit selected. In fact I'm pretty sure I've played a few RTS style games (Total War series, maybe?) that use a similar system.

[Mikademus]

It seems to me that the best (only?) solution here is to make the single click action benign enough that when the single click event occurs you can always go ahead and process it without caring whether or not it's going to be followed by a double click event. While you *could* work in some delays in event dispatching to try and distinguish the events, I expect that you'll get a lot of user complaints about it. UI "lag" is one of those things that people tend to almost universally hate.

With what you said you want, I think you're already fine in that area. If the user double clicks to focus on an object, then it's not terribly illogical to assume that they will want that unit selected. In fact I'm pretty sure I've played a few RTS style games (Total War series, maybe?) that use a similar system.

With all due respect, that is up to the application in question - quite unlike what you seem to be arguing for, there is no such thing as one best interface standard, even for RTT or RTS games (no, not even for selection or whatever else may be associated with mouse interaction and unit icons). My suggestions are about how to facilitate certain functionality and flexibility in a general-purpose library in a way that will require the application to explicitly activate features that may incur interface implications. If you hold that applications should compromise their design to accommodate limitations or shortcomings in their libraries I can only reply, as above, that I couldn't disagree more.

(That said; sure, many applications and cases will not see this particular functionality as critical. That does not change that other will: f.i. OGRE's BetaGUI [or was it QuickGUI?] is designed around the concept of exclusive ["cooked"] events. And yes, I still want to use CEGUI. Also, my last suggestion, about allowing injection of specific cooked events into CEGUI, is a minimal-impact solution that should satisfy all parts).

I apologise if my reply seems confrontational or aggressive, it was somewhat frustrating to see my earnest suggestion of how to achieve increased flexibility in an user interface library met with a reply that seems to say that "we don't need this, it is your interface design that is illogical".

[CrazyEddie]

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.

[Speedo]

With all due respect, that is up to the application in question - quite unlike what you seem to be arguing for, there is no such thing as one best interface standard, even for RTT or RTS games (no, not even for selection or whatever else may be associated with mouse interaction and unit icons).

I'm offering a potential solution which could save you all of the work you're looking at doing to deal with this very small problem - take it or leave it, doesn't really matter to me either way. But if you're going to get pissy and write out a half page rant in response to every suggestion you don't like, a public forum may not be the best place to ask your questions.

[Mikademus]

I'm offering a potential solution which could save you all of the work you're looking at doing to deal with this very small problem

Thank you for your kind consideration.

[Jamarr]

Now now, no need to get all riled up...

With a little effort I think you could implement something like I originally suggested: delayed dispatching of events based on window properties (eg 'cooked events') by adding a couple properties to CEGUI::Window, an event queue to CEGUI::System, and updating CEGUI::System::injectMouseButtonDown() and CEGUI::System::injectTimePulse() appropriately.

I glanced at CEGUI::System::inject* and honestly I don't think it would be that difficult...

[Mikademus]

With a little effort I think you could implement something like I originally suggested: delayed dispatching of events based on window properties (eg 'cooked events') by adding a couple properties to CEGUI::Window, an event queue to CEGUI::System, and updating CEGUI::System::injectMouseButtonDown() and CEGUI::System::injectTimePulse() appropriately.

I glanced at CEGUI::System::inject* and honestly I don't think it would be that difficult...

I'd rather not change my dependency libraries (I want as few update points as possible [CEGUI comes with OGRE for me]) but nonetheless, that would be something akin to my second suggestion--injecting cooked events into CEGUI-- right? I agree with you, that should be quite simple. At the moment I am cooking my own click events in my application, so injecting them would be very nice, and I also think it would be relatively easy to add to CEGUI. Nonetheless, CE seems to disfavour this model

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.

There are probably reasons for this I am not aware of, and CE had done an excellent job with CEGUI so even though I might be keen on certain features and will argue in favour of them I will not dispute his design decisions.

If anyone is interested in my event cooking code I'd be happy to share it, but it certainly isn't rocket science.

[Jamarr]

I'd rather not change my dependency libraries (I want as few update points as possible [CEGUI comes with OGRE for me]) but nonetheless, that would be something akin to my second suggestion--injecting cooked events into CEGUI-- right?

Not really. I ment that adding internal support to CEGUI for such a feature does not appear to be difficult. In otherwords, CEGUI can/should handle this internally. Like CE, I don't particularly like the idea of users having to inject those events themselves.

Since I do not have a need for such a feature, I'm not going to code it myself. But if you think it would be useful to others, and you want to keep your dependency libraries clean, you could just submit a patch to CEGUI so that this code would be included in future versions of the library. This way you are contributing to the project, and you won't have to manage these changes when upgrading to newer versions of the library.

[Mikademus]

Perhaps it may be of use if I list what I've had to manage to create this functionality. So the things you need to consider when designing event cooking are

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.