Some US keyboards have “” in a different place than others (left of
Bkspc versus below).
Some keyboards (esp. on laptops) really screw with the location of
some of the edit- and movement-related keys (like PgUp, Home, etc.).
Personally, I prefer keyboardswith:
Insert Home Page Up
Delete End Page Down
Then add all of the weird multimedia keys. I think having SDLK_* be
based on key location is kind of crazy.
-bill!On Sat, Jan 19, 2008 at 07:54:12PM +0100, Gerry JJ wrote:
As you can see, the z key is where it is on an US keyboard, but there’s
an extra key labelled ‘<’ between that and the left shift key (‘ls’).
Also, the enter key spans two rows, so there’s no equivalent for the
’’ key the US layout has.
Correct. It’s handled via SDL key input events, and the IM code that
lives in Tux Paint. (Sounds like you discovered that yourself. )
You can test it on pretty much any system, BTW. Try:
tuxpaint --lang japanese
Select the text tool in Tux Paint. (3rd row on the far left)
Click the canvas to enter text.
Press the Right ALT key on your keyboard.
Type [H] and then [A].
If you select an appropriate font (default Tux Paint 0.9.18 install w/
SysFonts turned off, the 2nd-to-last font, for example) and you should
see a Japanese ‘ha’ character.On Sat, Jan 19, 2008 at 09:23:25AM -0600, Bob Pendleton wrote:
Is this implementation independent of the OS/Windowing system?
Jeff wrote:> On Sun January 20 2008 09:18, list at akfoerster.de wrote:
Please don’t simply throw that away!
I currently write a fancy text-terminal emulator using SDL, so getting the
unicode character is very handy.
I second that. I use SDL 1.2 for non-game applications for which text input is
very important. I’m not currently using SDL 1.3 mostly because keyboard input
isn’t yet mature.
That’s what text input events are for in SDL 1.3. Piggybacking text
input onto key events was a suboptimal choice in SDL 1.2 that we’re
trying to correct.
Keep in mind that in general there is no 1-to-1 correspondence between
keystrokes and characters input - with dead keys and input methods,
multiple keystrokes can result in a single character, or with things
like handwriting recognition, characters could be input without any
keystrokes at all.
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?On Sun, 2008-01-20 at 09:15 +0000, Christian Walther wrote:
As you can see, the z key is where it is on an US keyboard, but there’s
an extra key labelled ‘<’ between that and the left shift key (‘ls’).
Also, the enter key spans two rows, so there’s no equivalent for the
’’ key the US layout has.
Some US keyboards have “” in a different place than others (left of
Bkspc versus below).
Some keyboards (esp. on laptops) really screw with the location of
some of the edit- and movement-related keys (like PgUp, Home, etc.).
Personally, I prefer keyboardswith:
Insert Home Page Up
Delete End Page Down
Then add all of the weird multimedia keys. I think having SDLK_* be
based on key location is kind of crazy.
Yeah, I thought so at first too. But, it kind of grows on you. I was
talking to a group of programmers the other night about this and and on
of the fellows uses a Dvorak keyboard, another was from Germany and so
uses a German keyboard. They both thought that anything that would make
sure that things like WASD input use the same physical keys no matter
what the keyboard lay out a very very good thing.
Of course, you can’t guarantee that key tables haven’t been played with
and remapped all over the place, but we can do our best.
Bob PendletonOn Sun, 2008-01-20 at 16:31 -0800, Bill Kendrick wrote:
On Sat, Jan 19, 2008 at 07:54:12PM +0100, Gerry JJ wrote:
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
Yes, the idea is just mapping the position dependent key into the layout
defined key, using Unicode where possible. e.g. mapping from the q positional
key to ‘a’ on french keyboards. This works just fine with greek keyboards,
since it would map to the appropriate unicode codepoint. Symbols which don’t
have a unicode equivalent, like keypad enter and so forth, would have an SDL
defined symbol that is outside the current Unicode space.
Most of the asian keyboards have the standard US layout printed on the keys
and enter a special input mode for entering asian characters. In this case
the positional key codes would be the USB defined set, the layout codes would
be the US keyboard codes, and asian characters would arrive as text input
events via the IME.
Ok, I have been through the code and the documentation and what you
describe appears to be what is implemented. But, until I reread your
last paragraph above for the third or fourth time I did not “get” (and I
may still not get) what you just said. I still do not see how to get the
Greek or Farsi key symbol from a key code?
How does this work for the Chinese programmer? If he wants to do WASD
input he uses SDLK_W and so on. Now, he wants to use a specific Chinese
keycap symbol in his code for the equivalent of ‘Z’ for zoom. He can
either use the US keyboard names, or he can force his users to go
through the IME to enter the Chinese character.
Is that a correct interpretation of what SDL_GetLayoutkey and
SDL_Getkeyname are supposed to do?On Sun, 2008-01-20 at 11:03 -0800, Sam Lantinga wrote:
What follows is what I thought it was supposed to do:
The key press/release event returns a positional SDLK_*
The text input events returns the composed character(s) from IMEs and
from normal shift keys and so on.
I thought SDL_GetLayoutkey() just handled key position swaps, that is it
handled cases where z and y and a and q were swapped around on European
keyboards. That was wrong.
I thought SDL_Getkeyname() was supposed to return the actual Unicode for
the locale dependent key cap on the key. This also was wrong. As I
understand it SDL_Getkeyname() never returns the actual key symbol for
languages like Chinese, Greek, and Farsi. Is that correct?
As I currently understand it, and I do not claim that I do, there is no
way to get the actual symbol on the key board on a key press by key
press basis. Is that correct?
It seems to me that what we have here is a case where my preconceived
ideas are so different from y’alls that we are not communicating much at
all. I’m trying to work that out.
I am quite happy with the current plans for key press events and for
text input events. They let me get text in a reasonable way and they let
me get positional key codes which is something I really like. I like
adding bits to identify different keys types.
I would like to have a function called something like SDL_GetKeysymbol()
that takes the SDLK_* from a key event and returns either the Unicode
code point for the Key Symbol on the key or the SDLK_* for the key. If
the key does not have a Unicode code point then it returns the SDLK_*
otherwise it returns the Unicode code point. On a Greek keyboard it
would return a Greek Unicode code point, on a Farsi keyboard it would
return the Farsi Unicode codepoint. The SDLK_* would have a high order
bit set to distinguish them from the Unicode code points. The existing
SDL_PHYSICAL_KEY does that just fine.
Bob Pendleton
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.
Me neither, can you elaborate?
See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
Good point. Then we agree that it it necessary to be able to get the key
symbol for each key press.
Yes.
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?
It probably doesn’t now, but it should, conceptually.
Most Chinese keyboards have US layout and then input Chinese via an IME,
so the value returned for a specific key would be the english letter, or
for those that don’t have US layout, it would be the very basic sound
printed on the keyboard (which may not correspond to a complete glyph)
I don’t have first hand experience with these keyboards, so if you have
more experience with alternative keyboard layouts, please chime in!
First off, why is it ‘z’ instead of ‘Z’? I’ve never seen a keyboard with
a lower case ‘z’ on it?
The idea was it would be the key that is generated by pressing the key
without any modifiers, which then evolved since that didn’t make any
sense for composition keys, caps lock, enter vs return, etc.
It probably should be ‘Z’, but it’s open for discussion.
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.
Yes, I’m concerned about the extra bits for keypad key and special layout key.
Can we implement this without those special markers?
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?
I imagine it would return ‘Z’
See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
Is that a correct interpretation of what SDL_GetLayoutkey and
SDL_Getkeyname are supposed to do?
SDL_GetLayoutKey() returns the Unicode codepoint or SDLK_* constant for the
key, as printed on the keyboard with the current layout.
SDL_GetKeyName() takes a Unicode codepoint or SDLK_* constant and returns
a human readable name, UTF-8 for a Unicode codepoint, or some predefined
token for the SDLK_* constants.
Note that SDL_GetKeyName() returns the same thing regardless of where the
constant comes from, so it can be used for either a physical key or a layout
key.
Does that clarify things?
I’m a little iffy on adding extra bits to identify key types, as I can see
that getting out of hand very quickly. e.g. Oh, I need a bit for function
keys! Oh, and non-standard web/calculator/etc keys!
Christian, does this all sound correct to you?
See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
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.)
SDL_GetLayoutKey() returns the Unicode codepoint or SDLK_* constant for the
key, as printed on the keyboard with the current layout.
Not quite “as printed” insofar as the printed character, on Latin
keyboards, is usually in uppercase, while the layout key code is the
code point for the lowercase character (unless we want to change that).
SDL_GetKeyName() takes a Unicode codepoint or SDLK_* constant and returns
a human readable name, UTF-8 for a Unicode codepoint, or some predefined
token for the SDLK_* constants.
Right.
Note that SDL_GetKeyName() returns the same thing regardless of where the
constant comes from, so it can be used for either a physical key or a layout
key.
Right. It must be that way because there are values (like SDLK_RETURN)
that occur both as physical key codes and as layout key codes. For
values that only occur as physical, but not as layout key codes (like
SDLK_A), it deliberately returns a “programmer-readable” name rather
than a “user-readable” one (“SDLK_A” instead of “A”) to discourage use
of SDL_GetKeyName() directly on physical key codes without an
intervening SDL_GetLayoutKey() (except for debugging purposes) because
the output of that likely doesn’t match what the user sees on his keyboard.
I’m a little iffy on adding extra bits to identify key types, as I can see
that getting out of hand very quickly. e.g. Oh, I need a bit for function
keys! Oh, and non-standard web/calculator/etc keys!
We need a bit to distinguish SDLK_ codes from unicode codes. Whether
that’s a magic bit or not is in the eye of the beholder, it can be
regarded as either “SDLK_ codes are in the range 0-0x102 and have
SDL_KEY_CAN_BE_PHYSICAL_BIT (= 1<<24) set” or “SDLK_ codes are in the
range 0x01000000-0x01000102”.
We (or should I say I) want
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_1)) == "1"
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_KP_1)) == "[1]"
in a US layout and
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_1)) == "?"
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_KP_1)) == "[?]"
in an Arabic layout. If you see a way of achieving that without an
SDL_KEY_KEYPAD_BIT in the layout key code, I’d be happy to hear about it.
SDL_KEY_LAYOUT_SPECIAL_BIT is currently unused, and it may stay unused
forever, so I’m not opposed to dropping it.
The thing to keep in mind, I guess, is that these bits are not meant for
the SDL user. They are used in the inner workings of SDL itself. Unless
these inner workings change, there is no necessity to respond to
requests such as “Oh, I need a bit for function keys!”
Den Sat, 19 Jan 2008 15:10:16 -0600
skrev Bob Pendleton :
Theory has to conform to reality, so it is not the case that the key
directly to the right of the left shift key is always SDLK_Z. But,
oddly enough, the key in the location of the US Z key on the Norwegian
keyboard will still be SDLK_Z because the left shift key was split in
half on the Norwegian keyboard to make room for the extra key.
Makes sense.
All those extra keys have names defined for them in SDL 1.3. The names
may not be obvious or even reasonable but they are all based on the
names given to keys in the USB standard for keyboard devices which you
can find at http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
That gives us a pretty good, if not perfect, way to make sure that
the same key position has the same SDLK_* name on every keyboard.
Great! =)
The (I can only call it) “USness” of the names is from the standard
and does not represent any anti-international bias on the part of the
SDL developers
Nah, I didn’t think so either =). I didn’t really think there was a
problem, just wanted to get some things clarified.
SDL_GetLayoutKey() returns the Unicode codepoint or SDLK_* constant for the
key, as printed on the keyboard with the current layout.
Not quite “as printed” insofar as the printed character, on Latin
keyboards, is usually in uppercase, while the layout key code is the
code point for the lowercase character (unless we want to change that).
SDL_GetKeyName() takes a Unicode codepoint or SDLK_* constant and returns
a human readable name, UTF-8 for a Unicode codepoint, or some predefined
token for the SDLK_* constants.
Right.
Note that SDL_GetKeyName() returns the same thing regardless of where the
constant comes from, so it can be used for either a physical key or a layout
key.
Right. It must be that way because there are values (like SDLK_RETURN)
that occur both as physical key codes and as layout key codes. For
values that only occur as physical, but not as layout key codes (like
SDLK_A), it deliberately returns a “programmer-readable” name rather
than a “user-readable” one (“SDLK_A” instead of “A”) to discourage use
of SDL_GetKeyName() directly on physical key codes without an
intervening SDL_GetLayoutKey() (except for debugging purposes) because
the output of that likely doesn’t match what the user sees on his keyboard.
I’m a little iffy on adding extra bits to identify key types, as I can see
that getting out of hand very quickly. e.g. Oh, I need a bit for function
keys! Oh, and non-standard web/calculator/etc keys!
We need a bit to distinguish SDLK_ codes from unicode codes. Whether
that’s a magic bit or not is in the eye of the beholder, it can be
regarded as either “SDLK_ codes are in the range 0-0x102 and have
SDL_KEY_CAN_BE_PHYSICAL_BIT (= 1<<24) set” or “SDLK_ codes are in the
range 0x01000000-0x01000102”.
We (or should I say I) want
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_1)) == "1"
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_KP_1)) == "[1]"
in a US layout and
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_1)) == "?"
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_KP_1)) == "[?]"
in an Arabic layout. If you see a way of achieving that without an
SDL_KEY_KEYPAD_BIT in the layout key code, I’d be happy to hear about it.
Yeah, that really bothers me. Specifying how the names of keypad keys
are formatted seems like something that should not be part of SDL. I’m
an old X guy and believe in “mechanism, not policy” or as I like to say
it “tools, not rules”. In my opinion, the above code sequences should
should behave this way:
It should be up to the programmer to decide how to indicate that one key
is on the key pad and one is not. He has that information, either from
the symbol name, or from the “magic” bit that is currently part of the
SDLK_* definitions.
Hmmm… I think we do nee a magic bit to distinguish between Unicode
code points and SDLK_, but a simple table look up can tell us that an
SDLK_ can tell us that a key is on the key pad. Can’t it? Tables can
replace magic bits and programmers who want them can code them.
Bob Pendleton
SDL_KEY_LAYOUT_SPECIAL_BIT is currently unused, and it may stay unused
forever, so I’m not opposed to dropping it.
The thing to keep in mind, I guess, is that these bits are not meant for
the SDL user. They are used in the inner workings of SDL itself. Unless
these inner workings change, there is no necessity to respond to
requests such as “Oh, I need a bit for function keys!”
You have to be very careful about phrases like “meant for” because it
doesn’t matter who or what they are “meant for”. Programmers will use
them if they are there. Not to mention that you, Sam, and I are all
users and we can ask for lots of extra bits for this and that. OTOH, if
we are going to mix SDLK_* and Unicode code points into the same 32 bit
values then we have to make sure that Unicode code point values and
SDLK_* values are disjoint. I like the idea of using a bit for that, and
I happen to like the sign bit, but that is just me
Bob PendletonOn Tue, 2008-01-22 at 21:04 +0100, Christian Walther wrote:
(I suspect it should actually convert it to “?” - any Greeks here
who can confirm whether Greek keyboards are labeled in upper- or
lowercase?)
(A quick Google Images search shows uppercase labels on the keyboard.
So, ?.)
A little question: is SDL_GetKeyName() supposed to return user-visible
names? So, if for SDLK_UP it returns the string “Up”, will it be
localized, or at least guaranteed to not change between drivers, so
that an app can apply localization afterwards?
(Nitpickin’.)
?Il giorno 22/gen/08, alle ore 20:22, Christian Walther ha scritto:
It should be up to the programmer to decide how to indicate that one key
is on the key pad and one is not. He has that information, either from
the symbol name, or from the “magic” bit that is currently part of the
SDLK_* definitions.
Hmmm… I think we do nee a magic bit to distinguish between Unicode
code points and SDLK_, but a simple table look up can tell us that an
SDLK_ can tell us that a key is on the key pad. Can’t it? Tables can
replace magic bits and programmers who want them can code them.
I agree. We can use a lookup table if we want to define them differently.
In fact… perhaps we should use the actual name of the constant? That
way it can be localized however the application wants.
e.g. SDLK_KP_1 -> “KP_1”
I’m not sure, you could also argue that the english name could be simply
used as a key into a localized table.
Anyway, I’m rambling.
See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
I’m sorry folks, When I reread what I have written today it is more
disjointed than usual and some of it seems belligerent even to me, and I
wrote it. I’m not usually this bad. Please don’t take it personal.
The only excuse I can give is that I fell about half way through from my
attic to my bedroom last night and I am more than a little beat up.
Usually I don’t have, or need, an excuse for acting like an asshole…
But, I do try not to.
Bob PendletonOn Tue, 2008-01-22 at 14:35 -0600, Bob Pendleton wrote:
On Tue, 2008-01-22 at 21:04 +0100, Christian Walther wrote:
Sam Lantinga wrote:
SDL_GetLayoutKey() returns the Unicode codepoint or SDLK_* constant for the
key, as printed on the keyboard with the current layout.
Not quite “as printed” insofar as the printed character, on Latin
keyboards, is usually in uppercase, while the layout key code is the
code point for the lowercase character (unless we want to change that).
SDL_GetKeyName() takes a Unicode codepoint or SDLK_* constant and returns
a human readable name, UTF-8 for a Unicode codepoint, or some predefined
token for the SDLK_* constants.
Right.
Note that SDL_GetKeyName() returns the same thing regardless of where the
constant comes from, so it can be used for either a physical key or a layout
key.
Right. It must be that way because there are values (like SDLK_RETURN)
that occur both as physical key codes and as layout key codes. For
values that only occur as physical, but not as layout key codes (like
SDLK_A), it deliberately returns a “programmer-readable” name rather
than a “user-readable” one (“SDLK_A” instead of “A”) to discourage use
of SDL_GetKeyName() directly on physical key codes without an
intervening SDL_GetLayoutKey() (except for debugging purposes) because
the output of that likely doesn’t match what the user sees on his keyboard.
I’m a little iffy on adding extra bits to identify key types, as I can see
that getting out of hand very quickly. e.g. Oh, I need a bit for function
keys! Oh, and non-standard web/calculator/etc keys!
We need a bit to distinguish SDLK_ codes from unicode codes. Whether
that’s a magic bit or not is in the eye of the beholder, it can be
regarded as either “SDLK_ codes are in the range 0-0x102 and have
SDL_KEY_CAN_BE_PHYSICAL_BIT (= 1<<24) set” or “SDLK_ codes are in the
range 0x01000000-0x01000102”.
We (or should I say I) want
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_1)) == "1"
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_KP_1)) == "[1]"
in a US layout and
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_1)) == "?"
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_KP_1)) == "[?]"
in an Arabic layout. If you see a way of achieving that without an
SDL_KEY_KEYPAD_BIT in the layout key code, I’d be happy to hear about it.
Yeah, that really bothers me. Specifying how the names of keypad keys
are formatted seems like something that should not be part of SDL. I’m
an old X guy and believe in “mechanism, not policy” or as I like to say
it “tools, not rules”. In my opinion, the above code sequences should
should behave this way:
It should be up to the programmer to decide how to indicate that one key
is on the key pad and one is not. He has that information, either from
the symbol name, or from the “magic” bit that is currently part of the
SDLK_* definitions.
Hmmm… I think we do nee a magic bit to distinguish between Unicode
code points and SDLK_, but a simple table look up can tell us that an
SDLK_ can tell us that a key is on the key pad. Can’t it? Tables can
replace magic bits and programmers who want them can code them.
Bob Pendleton
SDL_KEY_LAYOUT_SPECIAL_BIT is currently unused, and it may stay unused
forever, so I’m not opposed to dropping it.
The thing to keep in mind, I guess, is that these bits are not meant for
the SDL user. They are used in the inner workings of SDL itself. Unless
these inner workings change, there is no necessity to respond to
requests such as “Oh, I need a bit for function keys!”
You have to be very careful about phrases like “meant for” because it
doesn’t matter who or what they are “meant for”. Programmers will use
them if they are there. Not to mention that you, Sam, and I are all
users and we can ask for lots of extra bits for this and that. OTOH, if
we are going to mix SDLK_* and Unicode code points into the same 32 bit
values then we have to make sure that Unicode code point values and
SDLK_* values are disjoint. I like the idea of using a bit for that, and
I happen to like the sign bit, but that is just me
It should be up to the programmer to decide how to indicate that one key
is on the key pad and one is not. He has that information, either from
the symbol name, or from the “magic” bit that is currently part of the
SDLK_* definitions.
Hmmm… I think we do nee a magic bit to distinguish between Unicode
code points and SDLK_, but a simple table look up can tell us that an
SDLK_ can tell us that a key is on the key pad. Can’t it? Tables can
replace magic bits and programmers who want them can code them.
I agree. We can use a lookup table if we want to define them differently.
In fact… perhaps we should use the actual name of the constant? That
way it can be localized however the application wants.
e.g. SDLK_KP_1 -> “KP_1”
I like that, but I would have two tables, on that make SDLK_KP_1 to the
name KEYPAD and another that returns “1”.
I’m not sure, you could also argue that the english name could be simply
used as a key into a localized table.
Yep.
Anyway, I’m rambling.
Yeah, but remember that your rambles are taken very seriously.
Bob PendletonOn Tue, 2008-01-22 at 13:03 -0800, Sam Lantinga wrote:
See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
A little question: is SDL_GetKeyName() supposed to return user-visible
names? So, if for SDLK_UP it returns the string “Up”, will it be
localized, or at least guaranteed to not change between drivers, so
that an app can apply localization afterwards?
(Nitpickin’.)
The actual up-arrow symbol is a valid unicode character (’?’, U+2191).
Why not use that?–
Rainer Deyke - rainerd at eldwood.com
The actual up-arrow symbol is a valid unicode character (’?’, U
+2191).
Why not use that?
This is OK for iconographic keys, but not for keys that use text (for
example, one might want to localize “Delete” to “Canc” or “Home” to
"?" U+2196 NORTH WEST ARROW, which is what is printed on a standard
Italian keyboard).
?Il giorno 23/gen/08, alle ore 04:24, Rainer Deyke ha scritto:
The actual up-arrow symbol is a valid unicode character (’?’, U
+2191).
Why not use that?
This is OK for iconographic keys, but not for keys that use text (for
example, one might want to localize “Delete” to “Canc” or “Home” to
"?" U+2196 NORTH WEST ARROW, which is what is printed on a standard
Italian keyboard).
Then there is also the problem of typing an up arrow character. How did
you do that? Us folks who never have to use an input method to entire a
key wonder how you did that magic.
Bob PendletonOn Wed, 2008-01-23 at 10:54 +0100, ? wrote:
Il giorno 23/gen/08, alle ore 04:24, Rainer Deyke ha scritto:
