I’m going to be pretty much unavailable for the next three weeks (I’m
teaching three three hour lectures five days a week which means I am at
school 14 hours/day and sleeping the rest of the time).
I think we have been looking at this the wrong way. We are treating it
as a single two step process when what we have are two single step
I love the concept of location based scan codes. These have been needed
in SDL for a long time. We also need to be able to generate a lay out
(locale) based mapping of scan codes to key symbols and an equally lay
out (locale) base mapping from scan codes to printable names.
I propose that key events return scan codes with names based on the USB
I propose a function, SDL_GetKeySymbol(scan code), that returns either a
member of an enumeration with names like SDLK_KP_ENTER | (1 << 30) for
command keys and the Unicode code point for “Y” or “Z”. The scan code
SDL_SCANCODE_Y would map to “Y” on a US keyboard and “Z” on a German
keyboard. The only localization that this function would provide would
be key location transpositions like the Y/Z example.
This approach lets us handle WASD like location based input and “Z” for
zoom symbol based input. The key concept is that there are exactly the
same number of key symbols as there are scan codes. This is important.
So it is very fast and very flexible. I would like to see a function
that allows the application programmer to change the mapping table at
I propose one more function that maps scan codes to pretty names;
SDL_GetKeyName(scan code). The scan SDL_SCANCODE_KEYPAD_ENTER (how about
SDL_SC_KP_ENTER to save our aching fingers?) would be translated to
"[enter]" and each letter key would be translated to the utf8 for that
matches the key symbol. So, any transposition of keys done
SDL_GetKeySymbol() would also be done by SDL_GetKeyName(). Since there
must be the same number of key names, key symbols, and scan codes, the
translation and localization of key names can be done using a table
indexed by scan codes. That table should be modifiable at run time by
the programmer to make it as easy as possible to do full localization.
Name changes like the difference between the name of the “window” keys
on Windows, and the “command” keys on Macs could be handled at compile
time using conditional compilation in the translation table.
This approach gives a simple implementation that is nearly infinitely
flexible, can be tailored to different OSes at compile time, allows the
application programmer to set up any wanted translation, and, because it
is table based there is no cost to duplicating the key transposition
Let me know what y’all think and I’ll get back to you when I can.
Bob PendletonOn Sun, 2008-01-27 at 18:39 +0100, Christian Walther wrote:
Sam and I met on IRC to discuss how to simplify the SDL 1.3 keyboard
input system. Sam has posted a summary of the results to the mailing
list (http://article.gmane.org/gmane.comp.lib.sdl/35854), and we can
continue the discussion there, but in case you feel like reading
through the whole chat transcript, here it is. We don’t want you to
feel left out of the decision process after all the work you’ve done