Sdl_key_layout_special_bit

In the 1.3 source code the bit value SDL_KEY_LAYOUT_SPECIAL_BIT is
defined in SDL_keysym.h but never used. I believe that it is intended
to tag keys such as “enter” and “print screen”. Is that correct? Having
that bit set would make some code easier to write and I am willing to go
through and add it.

Also, as I read it, the documentation says that SDL_GetLayoutKey returns
the SDLK_* value for keys such as “enter” and and “print screen” and the
unicode code point for character input keys. Is the unicode code point
in UCS4 format? It seems like it should be.

Finally getting this worked out…

Bob Pendleton–
±-------------------------------------+

Bob Pendleton wrote:

In the 1.3 source code the bit value SDL_KEY_LAYOUT_SPECIAL_BIT is
defined in SDL_keysym.h but never used. I believe that it is intended
to tag keys such as “enter” and “print screen”. Is that correct?

No. That bit is not intended for any key on any keyboard I know, but as
a precaution for the future to allow handling of more exotic keyboards.
(that’s why it’s not used in my Cocoa and X11 implementations).

Let’s say that on an Osmoian keyboard layout the key with physical key
code SDLK_A is labeled “AB” (because it types “A” on Wednesdays and "B"
on other days). We therefore want
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_A)) to return “AB” with such a
layout. But that is neither the name of an SDLK_ constant nor a single
Unicode character, so this is not possible if SDL_GetLayoutKey(SDLK_A)
can only return SDLK_ codes (SDL_KEY_CAN_BE_PHYSICAL_BIT set) or Unicode
code points (SDL_KEY_CAN_BE_PHYSICAL_BIT not set). Instead, it should
return SDL_KEY_LAYOUT_SPECIAL_BIT | 17 (where 17 is an arbitrary number
identifying the AB layout key).
SDL_GetKeyName(SDL_KEY_LAYOUT_SPECIAL_BIT | 17) will then internally
call the driver’s GetSpecialKeyName() function, which should recognize
the 17 and return “AB”.

Does that make sense, or do you think that provision is unnecessary and
only complicates the code as long as it’s not used?

Having that bit set would make some code easier to write and I am willing to go
through and add it.

Then you should probably introduce another special bit for that
(SDL_KEY_CAN_BE_PHYSICAL_OR_LAYOUT_BIT or something). If I understand
you correctly, you want to tag those SDLK_ codes that can also occur as
layout key codes (not just as physical key codes)? That would be
approximately the ones whose default names in SDL_keynames.h are
user-readable rather than “SDLK_…”? That set is not strictly defined
though, since a driver is free to return any SDLK_ code from
GetLayoutKey() (if it has set an user-readable name for it using
SDL_SetKeyName()), in particular if it doesn’t have the notion of a
user-configurable keyboard layout (as alluded to in the comment to
GetLayoutKey() in SDL_sysvideo.h).

(As a side note, it is not required that SDL_GetLayoutKey() restricted
to that set be the identity, either - e.g. for someone who has remapped
the meanings of the ctrl and caps lock keys, it may make sense to have
SDL_GetLayoutKey(SDLK_CAPSLOCK) == SDLK_LCTRL. I don’t think this is
currently implemented, though.)

Also, as I read it, the documentation says that SDL_GetLayoutKey returns
the SDLK_* value for keys such as “enter” and and “print screen” and the
unicode code point for character input keys. Is the unicode code point
in UCS4 format? It seems like it should be.

Yes - and no, in some sense. The code point, also called “scalar value”,
is just a number identifying a character. Since we know that this number
is between 0 and 2^32-1 (0 and 0x10FFFF, actually), we may store it in a
Uint32 (which SDLKey is typedeffed as). This is completely independent
of the UCS-* and UTF-* encodings, which only come into play when a
sequence of characters is to be encoded into a sequence of 8-, 16-, or
32-bit integers. However, you are right insofar as the UCS-4 encoding of
a single-character string is a single 32-bit integer containing the
character’s code point.

Finally getting this worked out…

Please let me know if anything is unclear in the explanations above. I
just got out of hospital after (successful) appendix surgery and at
times I feel I’m not quite in possession of my full mental abilities
yet. :slight_smile: It’ll take me some time to catch up on all mailing lists and
stuff, too.

-Christian

Really good to hear that you are back with us. Thanks for the reply.

I have spent a good part of the last month looking at input in SDL1.3.
As you know I have looked at your code and I have added some code to
implement text input events and I’m currently working on adding code for
handling full character composition in the X11 version.

All through this I have been seriously bugged about something in this
design. Nothing wrong with the intent or the code, there just something
that makes me wonder about how generalizable it really is. To help me
figure it all out I am writing a document describing the entire
situation, goals, and how the equivalent is done in X. I will post that
when I am done with it and we can all debate it.

Bob PendletonOn Fri, 2008-01-18 at 10:22 +0100, Christian Walther wrote:

Bob Pendleton wrote:

In the 1.3 source code the bit value SDL_KEY_LAYOUT_SPECIAL_BIT is
defined in SDL_keysym.h but never used. I believe that it is intended
to tag keys such as “enter” and “print screen”. Is that correct?

No. That bit is not intended for any key on any keyboard I know, but as
a precaution for the future to allow handling of more exotic keyboards.
(that’s why it’s not used in my Cocoa and X11 implementations).

Let’s say that on an Osmoian keyboard layout the key with physical key
code SDLK_A is labeled “AB” (because it types “A” on Wednesdays and "B"
on other days). We therefore want
SDL_GetKeyName(SDL_GetLayoutKey(SDLK_A)) to return “AB” with such a
layout. But that is neither the name of an SDLK_ constant nor a single
Unicode character, so this is not possible if SDL_GetLayoutKey(SDLK_A)
can only return SDLK_ codes (SDL_KEY_CAN_BE_PHYSICAL_BIT set) or Unicode
code points (SDL_KEY_CAN_BE_PHYSICAL_BIT not set). Instead, it should
return SDL_KEY_LAYOUT_SPECIAL_BIT | 17 (where 17 is an arbitrary number
identifying the AB layout key).
SDL_GetKeyName(SDL_KEY_LAYOUT_SPECIAL_BIT | 17) will then internally
call the driver’s GetSpecialKeyName() function, which should recognize
the 17 and return “AB”.

Does that make sense, or do you think that provision is unnecessary and
only complicates the code as long as it’s not used?

Having that bit set would make some code easier to write and I am willing to go
through and add it.

Then you should probably introduce another special bit for that
(SDL_KEY_CAN_BE_PHYSICAL_OR_LAYOUT_BIT or something). If I understand
you correctly, you want to tag those SDLK_ codes that can also occur as
layout key codes (not just as physical key codes)? That would be
approximately the ones whose default names in SDL_keynames.h are
user-readable rather than “SDLK_…”? That set is not strictly defined
though, since a driver is free to return any SDLK_ code from
GetLayoutKey() (if it has set an user-readable name for it using
SDL_SetKeyName()), in particular if it doesn’t have the notion of a
user-configurable keyboard layout (as alluded to in the comment to
GetLayoutKey() in SDL_sysvideo.h).

(As a side note, it is not required that SDL_GetLayoutKey() restricted
to that set be the identity, either - e.g. for someone who has remapped
the meanings of the ctrl and caps lock keys, it may make sense to have
SDL_GetLayoutKey(SDLK_CAPSLOCK) == SDLK_LCTRL. I don’t think this is
currently implemented, though.)

Also, as I read it, the documentation says that SDL_GetLayoutKey returns
the SDLK_* value for keys such as “enter” and and “print screen” and the
unicode code point for character input keys. Is the unicode code point
in UCS4 format? It seems like it should be.

Yes - and no, in some sense. The code point, also called “scalar value”,
is just a number identifying a character. Since we know that this number
is between 0 and 2^32-1 (0 and 0x10FFFF, actually), we may store it in a
Uint32 (which SDLKey is typedeffed as). This is completely independent
of the UCS-* and UTF-* encodings, which only come into play when a
sequence of characters is to be encoded into a sequence of 8-, 16-, or
32-bit integers. However, you are right insofar as the UCS-4 encoding of
a single-character string is a single 32-bit integer containing the
character’s code point.

Finally getting this worked out…

Please let me know if anything is unclear in the explanations above. I
just got out of hospital after (successful) appendix surgery and at
times I feel I’m not quite in possession of my full mental abilities
yet. :slight_smile: It’ll take me some time to catch up on all mailing lists and
stuff, too.

-Christian


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


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

All through this I have been seriously bugged about something in this
design. Nothing wrong with the intent or the code, there just something
that makes me wonder about how generalizable it really is. To help me
figure it all out I am writing a document describing the entire
situation, goals, and how the equivalent is done in X. I will post that
when I am done with it and we can all debate it.

That sounds great, thanks Bob. :slight_smile:

-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

?Let’s look at the basics of keyboard input.

At the bottom level is the hardware. Keyboards send “scan codes” to the
operating system. The scan codes encode the location of a key and
whether is was pressed or released, nothing else. Scan codes are device
dependent. Every different type of keyboard generates slightly different
scan codes.

The operating system knows what kind of keyboard is attached and
converts scan codes into a small set of key codes. Key codes are mapped
one to one with scan codes. The scan code, what ever it may be, for
"enter" gets mapped to the key code for enter. Operating systems define
a set of key codes and stick to it. But, again, key codes are purely
positional. They do not tell you what character has been input, they
only tell you which key was pressed.

(Ok, that isn’t exactly true. The conversion from scan codes to key
codes can happen in the OS, or the windowing system. And, the user
usually has the ability to change a table that tells the which scan
codes map to which key codes. This means that anything we do can be
messed up by the users, and often is.)

So,

scan codes (device DEpendent) -> key codes (device INdependent)

If I type the key at the location of the “Z” key on a US qwerty keyboard
and press the key at the same location on a Dvorak keyboard I should get
the same key code no matter what is printed on the top of the key.

Key codes are used in two different ways. Individual key codes can be
mapped to key symbols. That is, you can find out what symbol is printed
on a specific key based on its key code. The trouble is that that key
symbol can be very different depending on the language supported by that
keyboard. The same key code can be mapped to many different symbols.
Many of the keys do not map to single letters, they map to phrases. For
example: the enter key maps to the phrase “enter” while the “L” key maps
to the single letter “L”. And, to make things more complex the letters
and phrases are in the language and alphabet (or ideograms) of the
language the keyboard supports.

Key symbols are not the end of the process. Sequences of key codes are
composed to create texts. A text is a letter or symbol in a language. In
English “a” and “A” and ^A (control A) are all different texts that are
entered by composing the key code for the “A” key with zero or more
modifier keys. In this case “A” was composed with no modifiers to get
"a", with the right shift key to get “A” and the right control key to
get ^A. The CJK languages (and many others) take composition to extremes
where entering a long sequence of key strokes yields a single character
or in some cases a sequence of characters. Input in those languages
usually goes through an IME (input method editor) which is a small
window that pops up to show you what character is being composed.

So,

key codes (language INdependent) -> key symbols (language DEpendent)

and,

sequences of key codes (language INdependent) -> texts (language
Dependent)

All the information about the key symbols and the rules for composing
symbols into texts is in the computer, either in the OS, or the
windowing system. The keyboard has no information. The keyboard just
tells you which key has been pressed.

Q:What do programmers want to do with a keyboard?

too.

Key position input.

Lets say we want to use WASD input for controlling motion in a game. We
want to use the keys based on their location, not based on what is
printed on the keys at those locations.

SDL 1.3 provides this type of input with key press and release events.
The events include an SDLK_* key name that is based on the location of
the key, not what is printed on the key. The names are based on key
symbols printed on a standard US English USB keyboard. No matter what is
printed on the key, if you press a key in the same location as the "W"
on a US keyboard you will get SDLK_W in the key pressed/released event.

Key symbol input.

Some times we want to know what is on the key cap of the key that was
pressed. For example: if I write a program that uses “Z” to mean “zoom
in” I want to know if the key with the “Z” printed on it was hit.
Trouble is that “Z” and some other keys move around from keyboard to
keyboard. In SDL1.3 SDLK_Z is supposed to be the key on the bottom row
of characters just to the right of the shift key no matter what is
printed on that key. But, on many European keyboards that key has a big
"Y" printed on it. That means that we can not use SDLK_Z to let us know
if the “Z” key was hit. 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.

(SDL1.2 mixed up these two problems and let us get the modified
character along with a key press. That has gone away in SDL1.3.)

I see two ways we can solve this problem. We could just send along the
key cap information with the key pressed event. Or, we can have a
function that given an SDLK_* returns the Unicode code point for the key
cap or 0 (zero) for keys like “enter” and “home”. It doesn’t need to do
anything special for key pad keys because the SDLK_* in 1.3 have a
special bit set for key pad keys.

A function like that would let me tell you that input is based on WASD
on a standard keyboard or some other 4 characters on a Greek, Arabic, or
Chinese, keyboard. Because I can look up the key symbol for the keys
independent of the language of the keyboard. Of course, it would not
solve all out internationalization problems but it would be nice. Having
this function means I do not need to send the key symbol in a key
pressed event.

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. 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. Considering that there
all major operating systems have spent years providing
internationalization I think we need to provide a system that makes use
of the existing infrastructure as much as possible.

Composed text input.

The text input event is designed to handle returning any sequence of
characters that can be created by any known composition system. It
completely solves the problem of inputing text in all known languages.
It may create some other interesting problems because of the need for
IMEs to pop up a window on top of the SDL window. But, it seems to
completely solve that problem.

How do existing systems solve the problem?

The X Window system solved this problem (sort of?) in the early '90s and
had to adapt to Unicode later on. In X an input event gives you the scan
code and X key code for a key. You can then look up the key symbol for a
key from the key code, or you can pass the event to a function that
composes key presses into texts. X make a clean distinction between scan
codes, key codes, key symbols, and texts.

X has 256 possible key codes that can be assigned to the physical keys
on a key board. That is big enough to handle the keyboards I every heard
of. But, the number of keys has nothing to do with the number of symbols
that can be printed on keys.

X has a huge number of possible key symbols. As it grew and was adopted
by more and more of the world many new key symbols were added. Currently
the complete set of official key symbols includes all the old ones and
all the possible Unicode code points. All told, X has a few million
possible key symbols.

It is pretty easy to create a mapping from X key codes to SDLK_* and
vice versa. Given an X key code it takes only a couple of function calls
to convert the key code to a UNICODE code point. It is a short trip from
key codes to Unicode.

All the work of mapping key codes to Unicode is already (supposedly) in
X. We do not have to do it.

What I would like to do/change in what we have right now?

(Yeah, I know some of this would cause lots of existing code to stop
compiling… But, this is a wish list and I’m kind of fussy :slight_smile:

I would really like to either get rid of the Unicode field in the key
press events or redefine it. If it were redefined it would, when
possible, return the Unicode code point for the key cap of the key that
was pressed. It would be set to zero for keys such as “home” and
"enter". Feel free to ignore this suggestion!

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.

I don’t see the need for any other functionality in the keyboard input
system.

BTW, when I was researching all this I ran into SDL-IM; a patch that
adds CJK character composition to SDL 1.2.8. You can find it at:
http://sdl-im.csie.net/

	Bob PendletonA:We want to do input :-) And, we would like a little help with output


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

And FWIW, support for CJK and other composed languages in Tux Paint’s
text tool was an oft-requested feature. Mark K. Kim looked at SDL-IM and
decided it wasn’t suitable for what we needed, and went ahead and added
IM support directly to Tux Paint. (Extensible via files that map keypresses
to texts/characters/phrases, plus some code to add any required logic.)

It’s been in Tux Paint since 0.9.17. 0.9.18 supports Japanese, Korean,
Traditional Chinese and Thai.On Fri, Jan 18, 2008 at 05:12:15PM -0600, Bob Pendleton wrote:

BTW, when I was researching all this I ran into SDL-IM; a patch that
adds CJK character composition to SDL 1.2.8. You can find it at:
http://sdl-im.csie.net/


-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

BTW, when I was researching all this I ran into SDL-IM; a patch that
adds CJK character composition to SDL 1.2.8. You can find it at:
http://sdl-im.csie.net/

And FWIW, support for CJK and other composed languages in Tux Paint’s
text tool was an oft-requested feature. Mark K. Kim looked at SDL-IM and
decided it wasn’t suitable for what we needed, and went ahead and added
IM support directly to Tux Paint. (Extensible via files that map keypresses
to texts/characters/phrases, plus some code to add any required logic.)

It’s been in Tux Paint since 0.9.17. 0.9.18 supports Japanese, Korean,
Traditional Chinese and Thai.

Is this implementation independent of the OS/Windowing system? If so it
might serve as the basis for a system independent IME that could be part
of SDL and therefore consistent and maintainable on all systems that SDL
supports.

So, I guess I am asking if I can look at that code and possibly include
in the SDL under SDL’s license.

	Bob PendletonOn Fri, 2008-01-18 at 18:08 -0800, Bill Kendrick wrote:

On Fri, Jan 18, 2008 at 05:12:15PM -0600, Bob Pendleton wrote:


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

BTW, when I was researching all this I ran into SDL-IM; a patch that
adds CJK character composition to SDL 1.2.8. You can find it at:
http://sdl-im.csie.net/

And FWIW, support for CJK and other composed languages in Tux Paint’s
text tool was an oft-requested feature. Mark K. Kim looked at SDL-IM and
decided it wasn’t suitable for what we needed, and went ahead and added
IM support directly to Tux Paint. (Extensible via files that map keypresses
to texts/characters/phrases, plus some code to add any required logic.)

It’s been in Tux Paint since 0.9.17. 0.9.18 supports Japanese, Korean,
Traditional Chinese and Thai.

I just did a very quick look at the code for im.c on sourceforge and I
am hopping up and down on one foot with excitement. If I read it
correctly it is a pretty damn complete input method that works on top of
SDL. That means it could be incorporated into the machine independent
part of SDL 1.3 and just work.

I have to admit that we may not want to use it because it will not be
visually the same as system dependent input methods that people are used
to, but it would sure be sweet to have this problem solved entirely
inside of SDL.

	Bob PendletonOn Fri, 2008-01-18 at 18:08 -0800, Bill Kendrick wrote:

On Fri, Jan 18, 2008 at 05:12:15PM -0600, Bob Pendleton wrote:


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

Den Fri, 18 Jan 2008 17:12:15 -0600
skrev Bob Pendleton :

Trouble is that “Z” and some other keys move around from keyboard to
keyboard. In SDL1.3 SDLK_Z is supposed to be the key on the bottom row
of characters just to the right of the shift key no matter what is
printed on that key.

You probably already know this, but that’s not entirely accurate… On
my keyboard, and all other norwegian keyboards I’ve ever seen, the key
just to the right of the left shift key is the ‘<’ key (shift for ‘>’),
and then the ‘z’ key is to the right of that. Of course, you already
mentioned that keyboard layouts differ, but it brings up a point, if
you bear with me for a little bit…

A standard US keyboard doesn’t have all the keys that keyboards from
other layouts have, like the aforementioned ‘<’ key. On the other hand
it has some keys that other layouts may not have, like the ‘’ key under
the backspace key (that key doesn’t exist on norwegian keyboards,
we’ve got a double-height and more narrow enter key in stead, making
room for another (different) extra key on the row below).

Also, some keys that are available with a single keypress on a US
layout may not be on other layouts. On an US layout you can just hit
the top left key to get a tilde. On the layout I’m using, to actually
write a tilde, you need to hold Alt Gr and press the rightmost key on
the second row twice. (That’s the key just left of the upper half of
enter. You can also press space in stead of the second press).

So, a US keyboard both contain “extra” keys and are missing other
keys compared to some other layouts. If a game wants to use the
physical ‘’ key as on an US keyboard, I’d be out of luck since there’s
no such key on my keyboard. Similarly, if a game wants to use the key
labelled ‘~’, that might be problematic. Other layouts would have
similar issues, not to mention small keyboards for handheld devices and
such that butcher the standard layouts completely…

Still, you’ve probably got to use something as a base, and the
standard US layout may be as good as any…

However, what if I wanted to use the physical ‘<’ key on my keyboard,
or any other key that doesn’t exist on a standard US layout? It
seems no different than if I’d wanted to use the physical ‘’ key
on a US layout. Using those keys would obviously be specific to that
physical layout, but if I had some reason to want to do it anyway, I
hope SDL would support it?

I guess the point I’m trying to make is that these extra keys have
standard positions for the layouts that have them, though different
layouts may have different extra keys. To support them all would
require some sort of superset of all the layouts, something that knows
of the presence of both the ‘|’ key under the backspace key on the US
layout, the more narrow enter key and extra keys on mine, and all the
others as far as it’s possible to combine them all.

  • Gerry

Den Fri, 18 Jan 2008 17:12:15 -0600
skrev Bob Pendleton <@Bob_Pendleton>:

Trouble is that “Z” and some other keys move around from keyboard to
keyboard. In SDL1.3 SDLK_Z is supposed to be the key on the bottom row
of characters just to the right of the shift key no matter what is
printed on that key.

You probably already know this, but that’s not entirely accurate… On
my keyboard, and all other norwegian keyboards I’ve ever seen, the key
just to the right of the left shift key is the ‘<’ key (shift for ‘>’),
and then the ‘z’ key is to the right of that. Of course, you already
mentioned that keyboard layouts differ, but it brings up a point, if
you bear with me for a little bit…

A standard US keyboard doesn’t have all the keys that keyboards from
other layouts have, like the aforementioned ‘<’ key. On the other hand
it has some keys that other layouts may not have, like the ‘’ key under
the backspace key (that key doesn’t exist on norwegian keyboards,
we’ve got a double-height and more narrow enter key in stead, making
room for another (different) extra key on the row below).

Thank you for helping me make this point. I believe that you are
mistaking the location of the key and the symbol printed on the key. In
fact, SDL should return SDLK_Z for the key < key on a Norwegian
keyboard. SDLK_Z is not meant to tell us anything about what is
printed on the key, it only gives us its location. Sadly, the location
information is encoded using the key symbols for a US keyboard. I think
it might be easier if they were just SDLK_1…SDLK_258 then people
would only get confused by the first 9 SDLK names and wonder where zero
is :slight_smile:

On keyboards that have keys in locations where the US keyboard does not
have a key SDL should return an SDLK_* that represents that extra
location on those key boards.

The new text input event returns the text encoded by a sequence of key
presses and on a Norwegian keyboard it would return < at the same time
that a key press event is returning SDLK_Z.

This problem, the difference between a keys location and the symbol
printed on it, is why we need to have a function to map SDLK_* values to
the symbols printed on the key caps. That function needs to return a
Unicode code point because a physical key might have a <, a Z, or a
Farsi, Korean, Chinese … character printed on top of it, if possible.

Also, some keys that are available with a single keypress on a US
layout may not be on other layouts. On an US layout you can just hit
the top left key to get a tilde. On the layout I’m using, to actually
write a tilde, you need to hold Alt Gr and press the rightmost key on
the second row twice. (That’s the key just left of the upper half of
enter. You can also press space in stead of the second press).

So, a US keyboard both contain “extra” keys and are missing other
keys compared to some other layouts. If a game wants to use the
physical ‘’ key as on an US keyboard, I’d be out of luck since there’s
no such key on my keyboard. Similarly, if a game wants to use the key
labelled ‘~’, that might be problematic. Other layouts would have
similar issues, not to mention small keyboards for handheld devices and
such that butcher the standard layouts completely…

Still, you’ve probably got to use something as a base, and the
standard US layout may be as good as any…

However, what if I wanted to use the physical ‘<’ key on my keyboard,
or any other key that doesn’t exist on a standard US layout?

No problem, you would just look for SDLK_Z and it will work. The idea is
to let you have to kinds of input, one based on the position of the key
and one based on the symbol on the key. If you always want to use the
key in the position of your < key you would look in key pressed events
for SDLK_Z and if you want to use the < symbol in your code you would
look for ‘<’ in text input events.

It
seems no different than if I’d wanted to use the physical ‘’ key
on a US layout. Using those keys would obviously be specific to that
physical layout, but if I had some reason to want to do it anyway, I
hope SDL would support it?

I guess the point I’m trying to make is that these extra keys have
standard positions for the layouts that have them, though different
layouts may have different extra keys. To support them all would
require some sort of superset of all the layouts, something that knows
of the presence of both the ‘|’ key under the backspace key on the US
layout, the more narrow enter key and extra keys on mine, and all the
others as far as it’s possible to combine them all.

  • Gerry

You point is absolutely valid and we are trying to solve it using to
different kinds of input, one based on key position and one based on key
symbol.

	Bob PendletonOn Sat, 2008-01-19 at 18:17 +0100, Gerry JJ wrote:

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


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

Den Sat, 19 Jan 2008 11:52:24 -0600
skrev Bob Pendleton :

Thank you for helping me make this point. I believe that you are
mistaking the location of the key and the symbol printed on the key.
In fact, SDL should return SDLK_Z for the key < key on a Norwegian
keyboard. SDLK_Z is not meant to tell us anything about what is (…)

No, I think you misunderstood me. On norwegian keyboards (as well as
some others), the left shift key is narrowed, so that there’s room for
an extra key between the left shift key and the z key. The main part
of my keyboard looks like this (use fixed width font):

[|][1][2][3][4][5][6][7][8][9][0][+][][b.spc]
[tab][q][w][e][r][t][y][u][i][o][p][?][?]<ent
[caps][a][s][d][f][g][h][j][k][l][?][?][’]\er/
[ls][<][z][x][c][v][b][n][m][,][.][-][r.shift]
[ct][wn][al][ space ][gr][wn][mn][ct]

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.

However, what if I wanted to use the physical ‘<’ key on my
keyboard, or any other key that doesn’t exist on a standard US
layout?

No problem, you would just look for SDLK_Z and it will work. The idea
is to let you have to kinds of input, one based on the position of
the key and one based on the symbol on the key. If you always want to
use the key in the position of your < key you would look in key
pressed events for SDLK_Z and if you want to use the < symbol in your
code you would look for ‘<’ in text input events.

So, the problem here is there’s no equivalent key on the US layout
(SDLK_Z is the z key), so what keysym should I look for for its
physical location?

  • Gerry

Hello !

[|][1][2][3][4][5][6][7][8][9][0][+][][b.spc]
[tab][q][w][e][r][t][y][u][i][o][p][?][?]<ent
[caps][a][s][d][f][g][h][j][k][l][?][?][’]\er/
[ls][<][z][x][c][v][b][n][m][,][.][-][r.shift]
[ct][wn][al][ space ][gr][wn][mn][ct]

This with the “<” key is also true for german keyboards
and also the thing with the tilde.

Would it not be helpfull to use a digi cam
and make a foto from the standard keyboards ?

A picture from a german keyboard,
a picture from a norwegian keyboard,

CU

This with the “<” key is also true for german keyboards
and also the thing with the tilde.

It’s common with most European keyboards, including my own Italian
one…

  • ?Il giorno 19/gen/08, alle ore 21:31, Torsten Giebl ha scritto:

Den Sat, 19 Jan 2008 11:52:24 -0600
skrev Bob Pendleton <@Bob_Pendleton>:

Thank you for helping me make this point. I believe that you are
mistaking the location of the key and the symbol printed on the key.
In fact, SDL should return SDLK_Z for the key < key on a Norwegian
keyboard. SDLK_Z is not meant to tell us anything about what is (…)

No, I think you misunderstood me. On norwegian keyboards (as well as
some others), the left shift key is narrowed, so that there’s room for
an extra key between the left shift key and the z key. The main part
of my keyboard looks like this (use fixed width font):

[|][1][2][3][4][5][6][7][8][9][0][+][][b.spc]
[tab][q][w][e][r][t][y][u][i][o][p][?][?]<ent
[caps][a][s][d][f][g][h][j][k][l][?][?][’]\er/
[ls][<][z][x][c][v][b][n][m][,][.][-][r.shift]
[ct][wn][al][ space ][gr][wn][mn][ct]

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.

That particular key is call non-US backslash in the USB standard and it
is called SDLK_NONUSBACKSLASH in SDL 1.3.

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.

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.

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 :slight_smile:

Bob PendletonOn Sat, 2008-01-19 at 19:54 +0100, Gerry JJ wrote:

However, what if I wanted to use the physical ‘<’ key on my
keyboard, or any other key that doesn’t exist on a standard US
layout?

No problem, you would just look for SDLK_Z and it will work. The idea
is to let you have to kinds of input, one based on the position of
the key and one based on the symbol on the key. If you always want to
use the key in the position of your < key you would look in key
pressed events for SDLK_Z and if you want to use the < symbol in your
code you would look for ‘<’ in text input events.

So, the problem here is there’s no equivalent key on the US layout
(SDLK_Z is the z key), so what keysym should I look for for its
physical location?

  • Gerry

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

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

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 “?”).

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

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?

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;
}

-Christian

Bob Pendleton writes:

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.

Please, everyone, have a look at
http://libsdl.org/cgi/viewvc.cgi/trunk/SDL/include/SDL_keysym.h?view=markup.
It has the definitions of all SDLK_ codes, with comments about the ones
that are different on different keyboard types (e.g. SDLK_NONUSBACKSLASH,
which is the extra key next to left shift on ISO (European) keyboards, or
SDLK_BACKSLASH, which lies in the corner of the L-shaped return key on ISO
keyboards and above the straight return key on ANSI (US) keyboards).

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

I can only add to this that it was me who came up with the current set of
SDLK_ codes (modeled after the USB standard), and I’m not American, I’m
Swiss :).

-Christian

Hello !

I heard that there are other languages where
you type in 4 characters for example and get only
1 character back. Would this also be handled by SDL
or do i need a different library for this ?

CU

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.

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.Am Sunday, dem 20. Jan 2008 schrieb Christian Walther:


AKFoerster

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.

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

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.

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