The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi,

In SDL 2, what is the recommended way of getting the unicode character
for a potentially modified keycode from a key press event?

For example, my program was previously reacting to the '~' unicode
value and now it gets the '`' sym with a shift modifier.

Cheers,
Richard.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think you just pick it up if i understand the question.
 
     {//add to the message
     status = event.key.keysym.unicode; //Get the keypress
     fout << "the key pressed was " << status << "  " << (char)status << endl;
     userInput = userInput + (char)status;
     }
 
This is a c/c++ method to get this key, show the keycode and press in a log, and add it to whatever the user is typing in a text field. This is default action of a switch case that was qualified to ensure expected input bounds. I only allow the standard keyboard keys but unicode is the easy way for keys.

On Thu, Aug 2, 2012 at 3:44 AM, Richard Tew wrote:

On Sun, Aug 5, 2012 at 1:40 AM, R Manard wrote:

In SDL2 this is deprecated.

typedef struct SDL_Keysym
{
SDL_Scancode scancode; /**< SDL physical key code - see
::SDL_Scancode for details */
SDL_Keycode sym; /**< SDL virtual key code - see
::SDL_Keycode for details */
Uint16 mod; /**< current key modifiers */
Uint32 unicode; /**< \deprecated use
SDL_TextInputEvent instead */
} SDL_Keysym;

The migration guide makes it clear that even if SDL_TextInputEvent
were implemented on other OS' than Windows or Cocoa, it would still be
unsuitable for use in responding to key presses ("to enter a small
text, rather than combining keys").

And that's why it's not quite as simple as using that field any more
:-) Or at least to my SDL newbie understanding. I would like this
functionality available in a cross-platform way, but hoping someone
else had been in this situation as well and had a solution.

Cheers,
Richard.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I guess they either destroyed or did not include a keyboard handler then. Sorry. You can always take sdl1 keyboard handling with you to sdl2. You would just cut it out of sdl1 and prefix the names on stuff like maybe SDLxxx_
 
Did they really do that?


On Sat, Aug 4, 2012 at 7:59 PM, Richard Tew wrote:

I guess they either destroyed or did not include a keyboard handler then. Sorry. You can always take sdl1 keyboard handling with you to sdl2. You would just cut it out of sdl1 and prefix the names on stuff like maybe SDLxxx_
 
Did they really do that?


On Sat, Aug 4, 2012 at 7:59 PM, Richard Tew wrote:

It was done quite some time ago (perhaps with the transition from 1.3
to 2.0?). The keyboard handling itself is actually still there.

According to the (sometimes unreliable) wiki, the closest replacement
is the keycode of the same structure (not the scan code! scan code ==
physical key, key code == logical key), but be warned that sometimes
the Unicode character isn't what's inside that field, so you'll need
to read the documentation before you use it.

However, if you want full support for Unicode then you'll need to use
the text-input system (there aren't any multi-thousand-key keyboards,
which is what you'd need for some of the Asian languages, so a
multi-step character-editing process is used instead). Full support
for Unicode with the old-style keyboard event just wasn't going to
happen (after all, how is SDL to know whether you want to treat a key
as an action button, or a text input method? Imagine a shooter-game
with a Unicode-supporting scoreboard, that also uses keyboard keys to
control the game).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Mon, Aug 6, 2012 at 7:37 PM, Jared Maddox wrote:

While text input may be a step forward, I don't quite get your
example. Key press events happening when a text field does not have
focus, can just be key presses. And when the text field has focus,
they can be IME-based text entry. This is the way it works in my
Chinese language Windows I believe. With regard to SDL2, I haven't
used the text entry API, but I expect a programmer calls
SDL_StartTextInput / SDL_SetTextInputRect when the focus arrives on
the text entry area and SDL_StopTextInput when it leaves. There
should be a clear delineation.

There's a valid use case for the ability to map a keycode and modifier
to the actual character on the user's keyboard. One that's completely
separate from text input. Maybe it isn't worth SDL2's time to support
it, but I am not sure I buy that the move to text input is the reason
it isn't worth supporting.

Cheers,
Richard.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That's the way it works, yes. I was just trying to point out why not
everything can be provided by the keyboard events: keyboard events
have to be dispatched "immediately", so they can't provide some
characters.


According to the wiki, to a certain extent SDL actually DOES do such a
mapping. If the high bit if the logical-key field is set, then it's
identical to the scancode, otherwise it's supposed to be the
appropriate Unicode value.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

So, this does this work? I'm not ready to sdl2 yet but it should be just as easy right yes?
 
 {//add to the message
     status = SDL_Keyboard.SDL_Keycode; //Get the keypress
     fout << "the key pressed was " << status << "  " << (char)status << endl;
     userInput = userInput + (char)status;
     }


On Tue, Aug 7, 2012 at 10:48 PM, Jared Maddox wrote:

Uh, that should be more like:

{
status = SDL_Keyboard.SDL_Keycode; //Get the keypress
fout << "The key's scancode is:" << SDL_Keyboard.Scancode;

if( status & HIGH_STATUS_BIT != HIGH_STATUS_BIT )
{
fout << " the unicode value is: " << (long)status <<
" the character is: " << (char)status;
// Even better: char32_t or it's C# version instead of char
}

fout << endl;
}

Remember: the keycode can carry a Unicode character, OR a scancode.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If you want to react to the key on the upper left of the keyboard with ~ and ` printed on it (on my keyboard), you should look for the scancode SDL_SCANCODE_GRAVE in the event.key.keysym.scancode field of key events.

If you want to look for the "~" key sequence regardless of how it's been entered, then you would watch for "~" in the event.text.text field of text input events.


See ya!

On Thu, Aug 2, 2012 at 1:44 AM, Richard Tew wrote:

so yes?
 
#1 i'm not looking for  SDL_Keyboard.Scancode and i'm not sure why i "should"
#2 if (HIGH_STATUS_BIT != HIGH_STATUS_BIT) //this is always false right?
#3 why is char32_t or it's C# version "better" than char?
#4 " fout << "the key pressed was " << status << " " << (char)status <<" is intended to show the int contained in status in regular and char form, does it not work?
#5 did you test this code?



On Thu, Aug 9, 2012 at 11:15 PM, Jared Maddox wrote:

I don't understand "react" or "look for". I'm sorry. Can you say this in code for me or tell me more please?

On Fri, Aug 10, 2012 at 1:19 AM, Sam Lantinga wrote:

On Fri, Aug 10, 2012 at 3:21 PM, R Manard wrote:


Scancodes are hardware codes generated by the keyboard when a certain key is pressed. They are meant to point to a single key on the keyboard regardless of what character value is mapped to it. If you assign a character value to keys, say "WSAD" which is common for first person shooters, there is no guarantee that "WSAD" will be in any sane place on a different keyboard layout, e.g. http://2.bp.blogspot.com/-gssMCfxhe8E/T44GCv0TKpI/AAAAAAAAAQg/qj4zjcB9F1Y/s1600/dvorak.png


Naming the scancodes SDL_SCANCODE_GRAVE is a bit misleading because really what that's trying to say is the "the key that generally refers to the ` ~ key on US-qwerty layouts." It very well may have a different sticker on it if you had a different keyboard even though it generates the same scancode. I don't use scancodes for that reason, or if I do, I treat them and opaque IDs because naming them truly has very little meaning.
 


No. The code was:


 if( status & HIGH_STATUS_BIT != HIGH_STATUS_BIT )


This checks to see if HIGH_STATUS_BIT was not set. The precedence rules will treat the expression as ((status & HIGH_STATUS_BIT) != HIGH_STATUS_BIT).




I'm assuming because a UTF32 representation can represent any unicode value, while a "char" generally means "8 bits" and can't fully represent any unicode character.
 


Outside of en_US and especially in CJK languages, 99% of the time a unicode value can't be represented by a C/C++ "char" variable. Thus, this will show the value as a true unicode value (is the word I'm looking for code point?) and what it appears as if it is truncated to an 8-bit value and displayed as a character value. The ASCII character set as unicode, for example, displays correctly if you truncate it to just 7 bits.
 

<snip>


No, I'm currently working on low-level stuff (a table with multiple
searchable fields, a MS-COM style system, some other stuff), and I
don't know what library (or language) your example was in, so I'm not
willing to spend the time to compile my version. My example was,
however, based directly off of your own.



Patrick covered this stuff pretty well.



react: act in reaction to something. "If you want to act in reaction
to the ~ key being pressed, then look for the SDL_SCANCODE_GRAVE
scancode."

look for: To search for something. "If you want to find the scancode
that was generated by a key-press, then look in the key.keysym field
of the event that was created in response to the key-press."




Precisely the reason. I initially used char as well, but before I hit
send it occurred to me that Unicode was involved, so I needed
something bigger.



I believe so, though I would say "the numeric value assigned to the
character" or something else verbose like that, since Manard seems to
be wrestling with English.

Basically, the version listed at #4 will list a number, then whatever
the Unicode character BECOMES when it is FORCED into a char.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Most of this does not apply to my code because as i mention  "This is default action of a switch case that was qualified to ensure expected input bounds. I only allow the standard keyboard keys but unicode is the easy way for keys." i get why someone else would maybe need to know that though so thanks for the experience divice (#4 #3 & #1)
#2 I believe you but please, the simple example type syntax is all i can understand most times. i do remember lerning that now that you say.
I'm hearing that full unicode support is not in sdl 2 yet. sdl1 had it and it was used. Why not give the same easy use to sdl2? This needs a new thread maybe.

On Fri, Aug 10, 2012 at 3:46 PM, Patrick Baggett wrote:

The problem is that the "easy use" unicode support is not the "right way".  You cannot actually support all of unicode with the SDL1 way, hence the need for a change.  The way SDL2 does it is not even less easy, it is just different, which does make it a little more work for those used to SDL1.

Jonny D

I dont remember that sdl1 unicode does not work. Can you link the bug report or something? i only know all my sdl1 unicode works great. since my new sdl2 code works as it's designed and i mentioned how it's easy, i think a person just needs to look at the code of sdl to get the use the want for their need. if they don't understand the sdl code it's hard unless the doc makes the user not nedd the unstanding. Let's get some doc for the functions that make no more need to understand the sdl code. i think that's too much to ask.
 
p.s. the "right" way is the way that delivers the expected results. the methods do not need to be what other people do. Code is art in my opinion every bit as it is science.
 
sdl mail ist disclaimer:
this is my opinion. opinions can be wrong. i have no opinion of the author(s) of materials other than those actually said, if any. my goal is to help claify and resolve the feature content. If i use the wrong word sometimetry to be kind.


On Sat, Aug 11, 2012 at 6:51 PM, Jonathan Dearborn wrote:

And in this case, your opinion is unfortunately wrong.

There are three options:

1) You just want to know when particular keys are pressed.
Answer) Use scancodes, and allow the user to remap keys whenever they want.

2) You want Unicode.
Answer) Use the text-editing events, because that's the only way that
you can get all Unicode characters.

3) You want to know when keys that map directly to Unicode are pressed.
Answer) Use keycodes, checking the high bit to determine if it carries
a Unicode value or a scancode value.

Those are the only three options. You say that SDL1's Unicode worked
for you? Nice, but the goal is for it to work in a more general sense.
In order to do that it needs to support the CJK characters, and to do
that the ability to modify the most recently entered character is
needed (because noone uses a keyboard big enough to provide all of the
Chinese or Japanese characters in any other way). Thus, the
text-editing api was added for the purpose of providing Unicode
support.

If you want to e.g. provide text-entry fields, then you need to
provide support for text-editing events. If you want to provide
shortcut keys (keys that cause an action to be performed when they're
pressed, such as opening a menu or moving a character on a screen)
then you should provide the users with a way to change which keys
provide which shortcuts.

As for Richard Tew's original post, it looks like option 1 or 2 is
correct for his situation.

You, on the other hand, have never mentioned what you want to use this
for, so we can't actually help you with this.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Mon, Aug 13, 2012 at 8:32 AM, Jared Maddox wrote:

Yes, option 1. If one needs to specify shortcut key mappings, both in
code and as representation to the user, in the form of scancode +
modifier then that's good to know and just how it has to be. It's
certainly not ideal for those who aren't trying to use unicode except
to know what key is pressed, but nothing ever is :-)

It would be nice to have this information included in the wiki though,
just so people know where they stand. I certainly would have
appreciated it. I tried to edit it myself and add something along
these lines, but it's not open for editing even if registered IIRC.
Then again, now that there are mailing list threads covering this they
should be locatable if anyone after not finding it in the wiki, does
the usual googling, so no biggie.

Cheers,
Richard.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

And in this case, your opinion is unfortunately wrong.

I said what it was for and what it did and, also, no one really cares if it works in a general sense, but, if it does what they want done, in my opinion. Where you are right is that if you understand the sdl code it's easy. So the authors question is answered and so is mine. Unless you want to sit around calling each other wrong someone should close the subject maybe.


On Sun, Aug 12, 2012 at 3:32 PM, Jared Maddox wrote: