[Fwd: Re: My thoughts on keyboard input in SDL 1.3]

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
processes.

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
standard.

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
run time.

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
operation.

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:

Hello Bob

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
recently!

-Christian


±-------------------------------------+

Sam and I met on IRC to discuss how to simplify the SDL 1.3 keyboard
input system.

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
processes.

Please don’t forget there is another process; input method.--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Hello !

Sam and I met on IRC to discuss how to simplify the SDL 1.3 keyboard
input system.

It would be interesting to hear how this is solved
in World of Warcraft. As such a game needs to ask
for keypresses and also for textinput.

CU

It would be interesting to hear how this is solved
in World of Warcraft. As such a game needs to ask
for keypresses and also for textinput.

It simply gets the keys based on the current layout. The issue here is
getting layout independent scancodes, which SDL 1.2 does not currently
support.

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Sam and I met on IRC to discuss how to simplify the SDL 1.3 keyboard
input system.

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
processes.

Please don’t forget there is another process; input method.

Nope, we haven’t forgotten it. The design for it is already solid. Sam
has added a text input event that gives you character values (in UTF8).
It is intended to give you characters that are the result of input
methods, or just plain shifting. The text input event is how you get "a"
from a single key press, “A” from shift+A, and a Chinese character, for
example, from an input method.

	Bob PendletonOn Thu, 2008-01-31 at 08:21 +0900, Alissa Sabre wrote:

Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±-------------------------------------+