andreas.raab at gmx.de
Sat Mar 19 05:10:47 UTC 2005
> That would be ok. ("Probably a comment should say something like
> "precomposed Unicode characters in UTF-32".) And defining the byte
> order would be necessary.
Huh? You see me confused. If UTF32 is a 32bit wide quantity then why
would we have to worry about it? We use 32bit "words" all the time
without worrying about byte ordering. What am I missing?
> And a tangent topic... If somebody wants to write an action game,
> she might want to design an interface that uses the shift-key to, say,
> charge the energy while the key is down, and shoot the cannon ball
> when the key is released. Probably two-player game in which each
> player uses the different shift key. I wonder if a "terminal mode" or
> something in which all the raw keycode (keyboard keycode) are reported
> to the image without cooking. That would allow us to experiment other
> type of interaction such as chord key input.
Err, Yoshiki, *please* tell me you have not been reading the two threads
before and in particular the three posts where I explained what I want
to be happening for keyDown vs. keyChar events. *Please*. Otherwise I
must assume that I am so terribly bad at explaining what I mean that
even three messages, all from different points of view, are not good
enough to explain what I mean.
Because... what you say in the above is what I have been advocating all
Four a fourth time from the beginning:
"keyDown" and "keyUp" events report raw (untranslated, uncooked,
whatever you name it) *keys*, that is individual keys on the keyboard,
such as, for example, the left-shift, or the right-shift, the F1, the
IME-Mode, or whatever else key.
"keyChar" (also known as: keyStroke) events report translated, cooked,
whatever you name it *characters* that is (typically) human-readable
entitities which are created by some means of combining the
aforementioned *key* events.
Therefore, if you would like to, you could compose and interpret the
keyDown character in any way you choose. So, indeed, it would be utterly
trivial to deal with other forms of interactions.
Sigh. I'm exhausted.
More information about the Vm-dev