On Tue, Feb 23, 2010 at 3:16 AM, Peter Wang
<novalazy@xxxxxxxxxx> wrote:
Imagine trying to write a simple text field with a generic event source instead
of a keyboard event source. When the user presses a key, you get a button_down
event with button_number=67. Then you have to figure out what letter that is
supposed to produce, but then you have to take into account shift states,
accents and input method, while the OS already does that. When the user
holds down the key, you get no repeat events either.
So, while there are sometimes advantages to treating all input devices as the
same, it's not always the case.
Text input is a wholly separate matter. And in my view it is not necessarily tied to input devices. What I'm interested in when the user inputs text is just to get events like INSERT_UNICODE, DELETE_CHARACTER, MOVE_CURSOR. This can be in response to a single key press, this can be in response to no (key repeat) or several key presses (dead keys, input methods), this can be in response to one or several touches (iphone).
In A5 we tied physical key presses to text input. ALLEGRO_KEY_DOWN is sometimes generated without a meaningful unicode field and sometimes it's generated without a meaningful keycode field. A cleaner solution could look like this:
EVENT_KEY_DOWN/EVENT_KEY_UP (and no repeat event): Those report key codes only but no unicode. There's never any special cases.
EVENT_TEXT_INPUT: This reports the unicode character (including control codes like delete or cursor move). If it is generated due to key repeat we could have a flag for it. Again, there's never any special cases.
The KEY events would be ideal for games and for assigning keyboard shortcuts. And now in fact they would be identical to generic buttons.
For text input, the TEXT_INPUT events would make things simpler - all you have to do is listen to a single event which tells you which unicode character to insert or whether the user wants to move the cursor or delete a character or is done with text input. And it would work great on the iphone, which can never generate proper KEY events yet fully supports text input.
That's not saying the current API doesn't work though. The ALLERO_EVENT_KEY_DOWN event may be a bit cobbled together but if we document how to use it for text input it should be fine. And I agree if we try to re-design things over and over until we have the perfect API there will never be an initial A5... so I'm not even suggesting we change how text input works at this point. The current API should be fine for quite some time in fact, once we add the mind reading capabilities for example we could simply generate multiple key down events, one for each letter of the thought :)