[SDL] My thoughts on keyboard input in SDL 1.3

[Christian Walther]

Bob Pendleton wrote:
> How does it work? I have been through that code and I do not get how it
> can possibly ever return a Greek or Chinese symbol?

SDL_GetKeyName(SDL_GetLayoutKey(SDLK_J)) in Greek on X11:

- reverse look-up of SDLK_J in keyCodeToSDLKTable to get an X11 KeyCode
- XKeycodeToKeysym() on that code returns XK_Greek_xi (0x7ee)
- KeySymToUcs4() (from imKStoUCS.c) converts that to code point 0x03be, 
GREEK SMALL LETTER XI.
- There are no special bits to add, so this is what's returned as the 
layout key code from SDL_GetLayoutKey().
- SDL_GetKeyName() converts that to the UTF-8 string "ξ" (0xCE 0xBE 
0x00) (I suspect it should actually convert it to "Ξ" - any Greeks here 
who can confirm whether Greek keyboards are labeled in upper- or lowercase?)

I don't know about Chinese, but if Sam is right about Chinese keyboards 
being labeled with Latin letters, then SDL_GetLayoutKey() should indeed 
never return the code point of a Chinese letter.

>>> All the work of mapping key codes to Unicode is already (supposedly) in
>>> X. We do not have to do it.
>> Is it? Support for mapping sequences of key codes to Unicode text is there.
>> Support for mapping a single key code to a Unicode key cap label is not, as
>> far as I can tell. Or why would we have had to include imKStoUCS.c?
> 
> This is a difference in point of view. We had to include imKStoUCS.c
> because it is not 100% guaranteed to be exported from X. But, we got it
> from the X11 code base. From my perspective that was all from X even
> though we had to grab it our selves.

Ah, OK.

At this point, it may be useful to mention that what imKStoUCS.c 
provides is not sufficient for our puposes - we need a few additional 
mappings in our own tables (X11_KeySymToSDLKey() is tried before 
KeySymToUcs4()). E.g. it doesn't include entries for dead keys or keypad 
operation keys (XK_dead_circumflex -> '^', XK_KP_Add -> '+'). Of course 
we could have merged everything into a single table, but it seemed more 
prudent to me in terms of maintainability to leave imKStoUCS.c unchanged.

>> switch (SDL_GetLayoutKey(event.key.keysym.sym)) {
>>   case 'z':
>>     zoom();
>>     break;
>>   case SDLK_KP_ENTER:
>>     accept();
>>     break;
>> }
> 
> First off, why is it 'z' instead of 'Z'? I've never seen a keyboard with
> a lower case 'z' on it?

Sam's idea was that the layout key code should be (derived from) the 
unicode code point of the character that is produced when the key is 
pressed without any modifiers.

SDL_GetKeyName('z') is "Z", this is what's printed on the key cap.

> They idea of SDL_GetlLayoutkey returning either Unicode or and SDLK_* is
> one I like. I am worried about what happens when they add more symbols
> to Unicode. Currently we are adding bits to mark a key as a physical key
> and as a key pad key and possibly a special layout key. I can see those
> bits being taken over for Unicode code points at some time in the
> future.

I can't find a better reference than 
<http://www.unicode.org/faq/blocks_ranges.html#2> (and other casual 
mentions around the FAQ) at the moment, but for all I know there is an 
agreement between the Unicode and ISO/IEC 10646 standards that there 
will never be any code point assignments outside of the range 0 - 
0x10FFFF. (This is the range that can be encoded by UTF-16.)

  -Christian