[SDL] Handling international characters

[Donny Viszneki]

On Jun 11, 2005, at 11:02 PM, Gabriel wrote:

> El s‡b, 11-06-2005 a las 18:54 -0400, Donny Viszneki escribi—:
>> SDL doesn't automatically handle the Shift key, nor Caps lock, nor 
>> compose
>> 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 
>> small
>> 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 
> to
> do game-style input you should use the SDLK_ constants anyway, so
> Unicode == 0 shouldn't matter; and if you're doing character input, 
> this
> 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.