|
|
On Sun, 2008-01-20 at 09:15 +0000, Christian Walther wrote:
> Bob Pendleton wrote:
> > Let's look at the basics of keyboard input.
>
> Thanks for taking the time to write this up, Bob! I agree with most of what
> you say and I think it's important to have this discussion here. The current
> SDL 1.3 key input design was roughly drafted in a chat session between me
> and Sam and fleshed out by me alone, and I'm very open to suggestions on how
> it can be improved.
>
> > We could just wait for a text input event that
> > will contain a either a "z", "Z", or ^Z depending on the state of the
> > modifier keys, which seems like a good idea to me, but it would be nice
> > to be able to get the the key symbol from a key press event. Not
> > necessary, but nice to have.
>
> In my opinion, this *is* necessary. What if the Z key is a dead key, i.e.
> only produces a text input event after another key has been pressed? Z is a
> bad example for this, but take e.g. grave: US keyboards have a grave key
> that could be handled by waiting for a text event containing "`". French
> keyboards have a grave key too (in a different place), but it's a dead key:
> a text event containing "`" is only generated there by pressing grave,
> space. If the user pressed grave, A, you'd miss the grave key press entirely
> (because the text event would contain "Ã").
Good point. Then we agree that it it necessary to be able to get the key
symbol for each key press.
>
> (Of course, using grave in a mnemonic mapping-by-symbol situation is a bad
> idea, since many keyboards don't have a grave key at all.)
>
> > The current API has a function that seems to solve the problem of key
> > transposition on European keyboards but that does not address the
> > problem of using a Greek or Chinese keyboard.
>
> Can you elaborate on this? As far as I can tell, it handles Greek just fine
> (I don't remember whether I've tested it on X11, but I'm sure I have on
> Cocoa). Of course, I don't have a Greek keyboard, so I can only test by
> using a Greek layout on my Swiss-German keyboard. I'm not familiar with
> Chinese keyboards at all, so I'll leave that to the people who are.
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?
>
> > There is also a function
> > to get the key cap, but the current implementation and the architecture
> > (in my possibly very wrong opinion) assume that code will be added to
> > SDL to address each different type of keyboard.
>
> I'm not sure what you're talking about here. Perhaps you're mistaken, or
> perhaps you're seeing a problem that I have missed so far. What exactly do
> you mean by "type"? ISO/ANSI/JIS? Mac/PC? US/German/Arabic/Norwegian/...?
>
> > 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. There are several (many) X11
extension APIs whose source code has been included in the SDL code base
because it is just easier than hoping that every who wants to compile
SDL has all those different development libraries installed.
>
> > I would really like to either get rid of the Unicode field in the key
> > press events
>
> Agreed.
>
> > or redefine it.
>
> The idea was not to include the layout key code (Unicode value for character
> keys) in the key event for efficiency - in many situations it is not needed,
> so we can save the cost of the translation. If needed, the user can do the
> translation from physical key code to layout key code using
> SDL_GetLayoutKey(). But I don't insist on this - API usability is more
> important than a hypothetical performance gain that we haven't even measured
> yet.
>
> > I want a function that given an SDLK_* would use the system provided (if
> > possible) internationalization code to return the Unicode code point of
> > the symbol on the key. It would return zero for keys like "home" and
> > "enter". This function solves the key symbol input problem.
>
> That would make the situation of a program that uses e.g. "Z to zoom, enter
> to accept" a bit more complicated compared to today:
>
> switch (SDL_GetUnicodeKeySymbol(event.key.keysym.sym)) {
> case 'z':
> zoom();
> break;
> case 0:
> switch (event.key.keysym.sym) {
> case SDLK_KP_ENTER:
> accept();
> break;
> }
> break;
> }
>
> rather than
>
> 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?
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.
Also, I do not understand how SDL_GetLayoutkey is supposed to work on a
Greek or Chinese keyboard. If I hit the what is SDL_GetLayoutkey
supposed to return when I pass it SDLK_Z when running in a Chinese
locale with a Chinese keyboard?
>
> -Christian
>
> _______________________________________________
> SDL mailing list
> SDL@xxxxxxxxxxxxxxxx
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
_______________________________________________
SDL mailing list
SDL@xxxxxxxxxxxxxxxx
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
|
|