Why do we have both injectKeyDown and injectChar?

[Clay]

I was hoping someone could explain why there is both an injectKeyDown and injectChar methods which must be called?

I'm starting work on writing a patch for repeating keys, but I ran into a problem where I have to know both the key code for injectKeyDown and the character for injectChar.

Since these methods must always be called as a pair, do you think a better solution would be to have this instead?
CEGUI::System::injectKeyDown(uint key_code);
CEGUI::System::injectKeyDown(uint key_code, utf32 code_point);

The first injectKeyDown would lookup the key character in a lookup table for a default language set and call injectChar itself, and the second method would take in the key code and the character for anyone who did not use the default language set.

The reason I need this is doing repeating keys needs to keep track of the last key to be injected into the system, and this means hooking into both of those methods...and possibly getting two unmatched calls to it.

If you think this is a good idea let me know and I'll submit a patch against 0.5.0 for it.

[CrazyEddie]

Hi

There are various reasons for this:

1) Some client code may need to be notified, via event subscriptions, of character events, of key down events, or of key up events. We provide all of these discreet possibilities to be as flexible as possible. The actual app writer will know where and when it would be appropriate to skip injection of any or all of these events - depending upon the needs of the individual app being developed. The library needs to reatain this flexability to be useful in all the alternative scenarios.

2) Not all key down events will translate to a character event. (F* keys, shift, alt, ctrl, etc, to name a few).

3) Nowhere is it stated that all key down injections be accompanied by a character injection, or that all character injections be accompanied by a key down / key up pair of injections. This is absolutely not the case, and in certain instances (see point 2), may make very little sense.

Additionally, CEGUI does no keymapping (another reason that chars are a seperate injection), and IMO should not do key mapping. There are likely other, more advanced systems for key-mapping, which we should not necessarily be tied to explicitly (again, for flexability purposes).

Just because certain example code, like the Ogre demos and the Ogre base application within the CEGUI samples framework, always inject a char along with a key down event, you will find that pretty much none of the other base applications take this approach - it was merely a convenience for using the Ogre integrated events. Other input libraries may indicate other, more appropriate, approaches to input injection.

Also note that depending upon the input library being used, key-repeat may already be implemented. It is for this reason that no integrated system was put into CEGUI in the first place, and in most cases, such functionality could (should?) be implemented as a layer between the input library and CEGUI itself.

Finally, please be aware that CVS HEAD (which will become 0.5.x) series code is exceptionally unstable. There are still huge chunks of code that are going to be ripped out; in some instances these will be replaced with entirely new, incompatible, replacements, and in other cases not replaced at all. Various usage patterns will be changing, and most code written against HEAD code now will definitely not be working come the end of, say, January next year. These changes may or may not include a total reworking of the way that inputs are collected and processed - I have made no firm decision on this as yet, but depending on how other changes proceed, it is probably more likely than not.

0.5.0 Will likely not see a release until very late Q1, possibly even (or maybe more likely) Q2 of 2006. Until then it is strongly advised that people use the 0.4.x series code. 0.4.1 will be released by the end of November and will be the last release until 0.5.0.

CE.

[Clay]

Ahhhh ok. It seems I had a braindead idea of how all of this was working. =)

This clears a lot up, thanks.

Don't worry about HEAD being unstable, I'm used to working with that kind of thing at work. =D