Hangar's picture

Character Events

I have a series of questions related to character events. I'm fleshing out the backbone for a gui and don't need it working that soon, but I want to avoid a complete redesign in the future.

1) In what release do you expect to implement character events?

2) How will you avoid redundancy between keyboard and character events? Will we get both an A keypress and an 'a' character message? Or will we get a keypress and have to request a translation to character event?

3) How will you handle surrogate pairs? Will character events come with one UTF-32 code-point or as paired UTF-16 events, or with a string?

4) How will you handle keyboard repeat? Can we expect one keyup event for each keydown event? Will we get a keydown event for each character event?

5) Can we turn off key repeat or character message translation?

6) Will there be any differences among the different OSes that you support?


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Quick answers (I have to get some sleep soon):

1) Cannot answer. They are a relatively low priority (you are the first to ask), but they are on the todo list.

2) I am thinking to keep character events completely separate from keypresses. For example, when compositing a character like Έ (accented capital epsilon), three keydown events will be reported (accent, shift and E) but only one character. The translation will be done automatically.

3) As far as I know, this is handled by the OS. I plan to support whatever the OS/runtime does, and nothing more.

4) I plan to have one keyup event for each keydown (may need some OS-specific workarounds here).

5) Key repeat is off by default, and you'll have to explicitly enable it. Note that preliminary support is already available, so you can already test it. I don't plan to provide a means to disable character events (just ignore them if you don't need them).

6) I'll try to provide consistent behavior.

Many things will depend on how X11 and MacOS handle character events (I'm only familiar with this code on windows).

Also, GameWIndow focuses on simplicity: if something is too difficult to support, it gets cut. If you plan to build a rich user interface, GTK# (or even Windows.Forms) is a safer bet.

Hangar's picture

I was just hoping to support a simple in-game gui with a modest amount of internationalization support. It sounds like what you're planning is sufficient.

BlueMonkMN's picture

I thought
1) The existing KeyPress event of System.Windows.Forms.Control handled that (is there some difference between the keypress' KeyChar property and the character you're looking for?)
2) System.Windows.Forms was common to the .NET framework across platforms

Was one of those assumptions wrong?

the Fiddler's picture

(1) is correct - if you are using WinForms, the KeyChar property is all you need.

(2) is not - WinForms are not covered by the .Net specs.

That's one reason why GameWindow does not rely on WinForms (there are others, but the why's off topic on this discussion - search the forums and/or post another topic if you are interested ;) )