0.7.x - Summary of the suggestion about cooked click events

Discussion regarding the development of CEGUI itself - as opposed to questions about CEGUI usage that should be in the help forums.

Moderators: CEGUI MVP, CEGUI Team

User avatar
Mikademus
CEGUI MVP
CEGUI MVP
Posts: 130
Joined: Wed Mar 18, 2009 19:14

0.7.x - Summary of the suggestion about cooked click events

Postby Mikademus » Wed Apr 15, 2009 19:39

I originally posted about the possibility of cooked events (a cooked event is f.i. a click or a double-click that doesn't generate prior mouseDown and moueUp evens) as a question in the beginners help forum, but it soon turned into a discussion about whether this could be a future part of CEGUI. For reference I though I would sum up the suggestion here.

-------------------------------------------------

Basically, while the usual sequence of events for a multi-click is
  • mousedown
  • mouseup
  • click
  • mousedown
  • mouseup
  • doubleclick
(repeat for tripleclick), some interface situations needs to have clicks and multi-clicks as discrete events without the proceeding mouseup and mousedown event.

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.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Thu Apr 16, 2009 08:38

Hi,

With reference to the topic subject, don't presume that this will be going into the 0.7.x series, or indeed that it will get added at all. All I have said is that I'll look into the possibilities, and that if we decide to add this, it might get into a 0.7.x release.

I must say that by keep "going on about it", as you are, the chances of this getting done are going down all the time. I have said I will investigate, and I will. The outcome of that investigation will determine if this request gets put in, once that decision is made, and if it's decided to put the feature in, further work will then be done on how best to implement it (from my perspective).

Currently there are quite a few other features and improvements to be done first (some are on mantis, some are not); many of these are things people have been waiting a couple of years for, so you can see that while the CEGUI feature addition wheel turns, it turns very slowly most of the time.

To give you more of an idea of release time scale, it is our intention to issue the first 0.7 release this year, however, work is progressing painfully slowly. The very earliest I can see a release is late July or August, and that's probably over optimistic. Subsequent releases in a series usually follow on a three month schedule.

"Nagging" away about something will not change the reality of all the points made above. I understand from your perspective you're probably not nagging, but from my perspective you are :P

CE.

User avatar
Mikademus
CEGUI MVP
CEGUI MVP
Posts: 130
Joined: Wed Mar 18, 2009 19:14

Postby Mikademus » Sat Apr 18, 2009 00:03

CrazyEddie wrote:Hi,

With reference to the topic subject, don't presume that this will be going into the 0.7.x series, or indeed that it will get added at all. All I have said is that I'll look into the possibilities, and that if we decide to add this, it might get into a 0.7.x release.

I must say that by keep "going on about it", as you are, the chances of this getting done are going down all the time. I have said I will investigate, and I will. The outcome of that investigation will determine if this request gets put in, once that decision is made, and if it's decided to put the feature in, further work will then be done on how best to implement it (from my perspective).

Currently there are quite a few other features and improvements to be done first (some are on mantis, some are not); many of these are things people have been waiting a couple of years for, so you can see that while the CEGUI feature addition wheel turns, it turns very slowly most of the time.

To give you more of an idea of release time scale, it is our intention to issue the first 0.7 release this year, however, work is progressing painfully slowly. The very earliest I can see a release is late July or August, and that's probably over optimistic. Subsequent releases in a series usually follow on a three month schedule.

"Nagging" away about something will not change the reality of all the points made above. I understand from your perspective you're probably not nagging, but from my perspective you are :P

CE.



Absolutely, my intention was not to nag or to presume that you've committed to my suggestion. Rather I was trying to be helpful by (squze the pun) cooking the thread content down to the essence and place it where it really belonged, here in the suggestion sub-forum. (You know, doing this was actually taking my time to try to give something back for your work already done and help given in the other forum). Be that as it may, atm it really doesn't matter for me anyway since I've implemented support for this in my project anyway.

I am a little miffed, though, that my genuine helpfulness was interpreted in the worst possible way (well, sorta), but then, this is the internet, and I've seen that many people here seems to make demands rather than show appropriate respect for effort spent etc, so I'd probably react the same way myself. Anyway, helpfullness can be just as annoying as genuine obnoxiousness, so I'll shut up now.

Cheers.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby CrazyEddie » Sat Apr 18, 2009 11:35

Hi,

It's not my intention to discourage people from trying to be helpful, I'd rather encourage such things :) Largely my post was meant in a light-hearted way as opposed to being admonishing (how dare you make suggestions! :lol: ). I also understood the purpose of collating all the info in one place. I guess mainly I wanted to re-iterate that it was something being considered rather than a 'done deal' (lest anybody get the wrong idea), and also to state that the decision might take some time to come to - since that's the way such things are :)

Btw, this post is also meant in a light hearted way :P

CE.

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby Jamarr » Mon Apr 20, 2009 15:53

So which method did you choose to implement? I am assuming #2 since you seem to be leaning towards that option, and since it likely requires the least amount of modification to CEGUI.

I still think #1 is better in the long-run, as clients would not need to write the event timing themsevles. Since CEGUI is already setup to handle timing via injectTimePulse(), it would only confuse/annoy users if they had to implement this themselves.
If somebody helps you by replying to your thread, upvote him/her as a thanks! Make sure to include your CEGUI.log and everything you tried when posting! And remember that we are not magicians!

User avatar
Mikademus
CEGUI MVP
CEGUI MVP
Posts: 130
Joined: Wed Mar 18, 2009 19:14

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby Mikademus » Sun Apr 26, 2009 17:39

Jamarr wrote:So which method did you choose to implement? I am assuming #2 since you seem to be leaning towards that option, and since it likely requires the least amount of modification to CEGUI.

I still think #1 is better in the long-run, as clients would not need to write the event timing themsevles. Since CEGUI is already setup to handle timing via injectTimePulse(), it would only confuse/annoy users if they had to implement this themselves.


Actually, I implemented method #1, but note that I haven't changed CEGUI's source: I use OIS for input handling and I extended my central input handling system to cook clicks, which in effect means that I am totally bypassing CEGUI's click subscription. Method #2 requires you to implement your own event cooking anyway, but it would be simpler I guess to add to the CEGUI code base. But I agree with you that if this was implemented in a framework, it would probably be better to offload event cooking from the user.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby CrazyEddie » Sun Aug 02, 2009 07:31

I have decided that for one of the first 0.7.x point releases this suggestion will be implemented, and surprisingly, will use the second suggested implementation of additional input injection functions for the click, double click and triple click events, along with an option to disable CEGUI's automatic click generation (since you're not likely to want that if you're injecting those types of event directly). Basically this gives the library user the power to deal with these things as they see fit, if such a need arises (albeit with the additional responsibility of ensuring they do not mess up the CEGUI internal state), while not bogging CEGUI down with a bunch of extra logic to handle these fringe cases. Additionally, it provides opportunities for other alternate behaviours without needing to mod the CEGUI core every time.

CE.

User avatar
Mikademus
CEGUI MVP
CEGUI MVP
Posts: 130
Joined: Wed Mar 18, 2009 19:14

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby Mikademus » Sun Aug 16, 2009 22:02

Some fast (and probably flawed) thoughts; since this is not going to break anything existing, perhaps we could implement this a bit more abstractedly?

Double- and triple-clicking are really multitapping a mouse button two or three times. That is, a multitap event is switching a particular digital input n times. Thus, perhaps a general TapEvent could be implemented (and injected) that contains which button was tapped and the number of times. Thus ButtonClick, ButtonDoubleClick and ButtonTripleClick (or whatever) events would really just be convenience shorthands for TapEvent(MB_left, 3) etc.

The advantage of this is threefold: first, we're not limited to 1, 2 or 3-tap events (though it is beyond me why anyone want to pump more than that in a GUI, although I remember a game where you could charge your magic discharge by buffering clicks). Secondly, we would have a uniform InputTapEventOrSomeName architecture. Thirdly, any button could be associated with a tap event, not only mouse buttons.

Ok, I was quite tired when writing down this and haven't thought through all aspects of it, so there's probably some good reason why this wouldn't work or fit it, but I think it is an idea worth sharing and putting up for discussion.

Cheers!

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby CrazyEddie » Mon Aug 17, 2009 08:41

Such a thing did briefly cross my mind when I was previously considering possible implementations, and I am in favour of more uniform APIs in general (honest! ;)). The thing about a 'tap' injection is (IMO) it's a separate thing from the existing click, double-click and triple-click events - at least without having a total change of direction within CEGUI (such a change in direction may not be a bad thing, though it's more of a change for a later - read 0.8.0 - version).

I think for 0.7.1 we can definitely get the new inject functions put in, and for a later version, it's certainly worth considering a more generic interface (and associated events) for mouse and key input.

CE.

User avatar
Mikademus
CEGUI MVP
CEGUI MVP
Posts: 130
Joined: Wed Mar 18, 2009 19:14

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby Mikademus » Tue Aug 18, 2009 18:49

Did you mean that "a change of direction within CEGUI" would be breaking the normal usage expectancy for clients of the API, or that it would require a significant rewrite of that part of the framework?

If the former, I had envisioned that there would be convenience events for clicks and double/triple-clicks that would retain the familiar "feel", but that would really be implemented on the abstract MultiTap classes/callbacks/whatnot.

If the latter, yeah, I'm with you about not biting off too much at once :)

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby CrazyEddie » Wed Aug 19, 2009 09:06

I meant a little of both ;) First let me specify that what I posted (and what I'm posting now) is not the result of any level of analysis at all, it's just the first thought / feeling that I get when looking at the high-level view of the concept.

Basically, I think we would be looking at not adding to the input injection interface; streamlining, replacing or reworking - yes, adding to - no. The reason I think this is that the more you add, the more complex it gets - while at the 0.7.x level we can add injectors for the click based events and yes it's therefore more complex (for some), but these are functions we can also use internally, so the code integrity and design is potentially improved by that. Having a whole additional paradigm for injecting certain events IMO just adds complexity and has large potential for confusion (have you read some of the questions on here! ;)). However, if we could replace the existing system with the new one, then that's a different matter - though this is where we get into the rewriting parts of CEGUI bit, and that's what pushes this out a bit further as far as potential releases.

CE.

User avatar
Mikademus
CEGUI MVP
CEGUI MVP
Posts: 130
Joined: Wed Mar 18, 2009 19:14

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby Mikademus » Thu Aug 20, 2009 21:47

Heh, yeah, then we're at the same wavelength. Though tip-toeing around it, I was actually suggesting a revamp of the input system :mrgreen:, where old interfaces, if required, would be provided by adaptors mimicking the old calls but built as convenience functions on top of the new system.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: 0.7.x - Summary of the suggestion about cooked click events

Postby CrazyEddie » Mon Aug 24, 2009 08:36

Cool ;) Depending upon how 0.7.0 is received, it should be possible to focus on a few of these areas that have been previously neglected to perhaps see where we can improve those things.

CE.


Return to “CEGUI Library Development Discussion”

Who is online

Users browsing this forum: No registered users and 12 guests