[SDL] Handling international characters
smirk at thebuicksix.com
Sun Jun 12 00:07:23 PDT 2005
On Jun 11, 2005, at 11:02 PM, Gabriel wrote:
> El sb, 11-06-2005 a las 18:54 -0400, Donny Viszneki escribi:
>> SDL doesn't automatically handle the Shift key, nor Caps lock, nor
>> keys, because SDL is for games, and we get a direct, low level
>> interface to the keyboard. It would be a nice project to create a
>> library to take responsibility for this task.
> I do use SDL for making games - and sometimes games need text input, to
> ask for the player's name, for example (it's exactly our case).
I wasn't trying to suggest that games don't require text input. I did
however fail to mention that the secondary complication involved in
creating cross-platform internationalized key composition is that
different operating environments have very different configurations.
For instance on Mac OS X, one pressed Option + N to compose the ÷
accent mark, and if the next letter I hit can have that accent applied,
then that is the character typed. Certainly this is different from
windows, which is in turn different from typical X configurations (as I
understand it the tilde key is involved in composing that particular
character in many default compose key configurations for X.)
> I could [try to] implement this myself, at least in Windows, Linux and
> Mac. The main question is, how should it work? Adding a new event type
> is probably out of the question.
> I think dead keys should generate SDL_KEYPRESSED and SDL_KEYRELEASED
> with 0 as the Unicode value (so you know they're dead keys) and the
> composite keys should have the composed value in Unicode. If you want
> do game-style input you should use the SDLK_ constants anyway, so
> Unicode == 0 shouldn't matter; and if you're doing character input,
> is how you'd like it to work.
> Comments? Suggestions?
Gladly. What you should do is create a function that accepts an
SDL_Event, and returns a unicode character, or NULL if a unicode
character is not resultant of the event it has accepted. Applications
can, when accepting text input, run all events through this function,
and if it returns NULL, it can handle the event itself. This is a very
common design strategy for any functionality meant to augment the event
processing loop. (Look at SDL_console for example, which in fact could
perhaps benefit from a function such as the one I am describing, heh.)
A second thing to consider is the current operating platform. On X the
application could try to figure out the user's compose-key
configuration. There may be a problem if different keyboard layouts on
Mac OS X use different compositions. Hmm I can probably try that right
now by changing my keyboard layout, just gimme a second here... zell
this is the french keyboqrd lqyout: the auick brozn fox ju,ped over the
lqwy dog: noz ti,e for qccents: Ïo ²² e: Ok yes on the French
keyboard layout, when I pressed Option + E, instead of creating an
acute accent and waiting on the next input to see which letter I will
apply, Mac OS X inserted an "."
An alternative to trying to decipher the keyboard layout, and then
emulate that operating environment's compose-key system, it's possible
that these platforms have provided ways to receive keyboard key presses
as a result of the user entering a compose-key.
Anyhow I don't think I said anything all that ground-breaking here, I'd
be surprised if you couldn't have figured all this out yourself. But if
anyone knows anything about that last part please share.
More information about the SDL