Quantcast

Arrow Keys, and keysym.unicode, SDL 1.2.10

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Arrow Keys, and keysym.unicode, SDL 1.2.10

Nigel Kerr-2
Good Folk,

I have some behavior that puzzles me a great deal about how arrow keys
are handled.  I would appreciate any sort of advice or insight.

I am on a Mac, a PPC iBook, 10.4.6 of the OS, using Xcode 2.2, with
SDL 1.2.10, and the extras package.

The smallest possible expression of my puzzling behavior was to add a
couple of lines to one of the sample applications for Xcode, in
TemplatesForXcode/SDL Application, I added to the main.c there the
following code in the event loop:

    case SDL_KEYDOWN:
        printf ( "keydown: %x %d\n", event.key.keysym.unicode,
event.key.keysym.sym ); break;
    case SDL_KEYUP:
        printf ( "keyup: %x %d\n", event.key.keysym.unicode,
event.key.keysym.sym ); break;

This sample application normally starts up, and waits for any
key-press to quit.  This addition should report, for every key down
and key up what the unicode and sym values are.

If I start this modified app, and then press on keyboard of my laptop
the left arrow, then the up, then right, then down, I get the
following output:

keydown: f702 276
keyup: f702 276
keydown: f700 273
keyup: f700 273
keydown: f703 275
keyup: f703 275
keydown: f701 274
keyup: f701 274

That the .sym field corresponds to the SDLK_LEFT, UP, RIGHT, and DOWN
is fine, but what puzzles me greatly are the Unicode values.  These
are private use area values (), and I am unsure what they mean.  I am
not sure who is giving me these values (Macosx?  SDL?); have I missed
in the documentation or mailing list what is intended?

This is puzzling because it the code I'm looking at (writ by others)
that does the following on a SDL_KEYDOWN event:

    if ((event.key.keysym.unicode && !handle(event.key.keysym.unicode)) ||
         (!event.key.keysym.unicode && !handle(event.key.keysym.sym))) {
          // handle unhandled stuff
     }

where handle above takes the value, and tries to make it up to various
SDLK_ values.  But SDLK_LEFT,RIGHT,UP,DOWN will never be sent to
handle: the unicode always has a value (because this is an app that
wants to be internationalized, and has SDL_enableUnicode on).

So maybe I'm asking for advice: should I try to handle the
"command-like" non-printing characters first before anything else?  Is
there a pattern used here?  Any information appreciated.

cheers,
nigel

_______________________________________________
SDL mailing list
[hidden email]
http://www.libsdl.org/mailman/listinfo/sdl
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Arrow Keys, and keysym.unicode, SDL 1.2.10

Christian Walther
Nigel Kerr wrote:

> If I start this modified app, and then press on keyboard of my laptop
> the left arrow, then the up, then right, then down, I get the
> following output:
>
> keydown: f702 276
> keyup: f702 276
> keydown: f700 273
> keyup: f700 273
> keydown: f703 275
> keyup: f703 275
> keydown: f701 274
> keyup: f701 274
>
> That the .sym field corresponds to the SDLK_LEFT, UP, RIGHT, and DOWN
> is fine, but what puzzles me greatly are the Unicode values.  These
> are private use area values (), and I am unsure what they mean.  I am
> not sure who is giving me these values (Macosx?  SDL?); have I missed
> in the documentation or mailing list what is intended?

These values come from Mac OS X. Apparently Apple (or NeXT before them)
decided that the arrow keys should generate character codes too.

See <http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT>
(or other pages reached from <http://www.google.com/search?q=U%2BF700>).

As far as I know the SDL documentation does not specify that
non-character-keys should not generate Unicode values, so the observed
behavior of the Mac OS X (Quartz/Cocoa) backend seems to be OK.

> So maybe I'm asking for advice: should I try to handle the
> "command-like" non-printing characters first before anything else?

That's what I do.

I wouldn't spend too much work on this issue though, as the keyboard
handling is supposed to be rewritten for 1.3 anyway, and who knows how
this will work then.

  -Christian


_______________________________________________
SDL mailing list
[hidden email]
http://www.libsdl.org/mailman/listinfo/sdl
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Arrow Keys, and keysym.unicode, SDL 1.2.10

Nigel Kerr-2
Christian,

Thank you for this informative response!  What I am thinking now:

since this has to do with Macosx, I should try to introduce a function
that knows about these mac-ism's, returns the sym value when one of
these mac PUA unicode values comes along, and is used at one strategic
point.  Since its a cross-platform app, I need to limit the scope of
the change as much as possible, and not ask for big logic changes
surrounding this issue.

Thanks again!

cheers,
nigel

On 6/25/06, Christian Walther <[hidden email]> wrote:

> Nigel Kerr wrote:
> > If I start this modified app, and then press on keyboard of my laptop
> > the left arrow, then the up, then right, then down, I get the
> > following output:
> >
> > keydown: f702 276
> > keyup: f702 276
> > keydown: f700 273
> > keyup: f700 273
> > keydown: f703 275
> > keyup: f703 275
> > keydown: f701 274
> > keyup: f701 274
> >
> > That the .sym field corresponds to the SDLK_LEFT, UP, RIGHT, and DOWN
> > is fine, but what puzzles me greatly are the Unicode values.  These
> > are private use area values (), and I am unsure what they mean.  I am
> > not sure who is giving me these values (Macosx?  SDL?); have I missed
> > in the documentation or mailing list what is intended?
>
> These values come from Mac OS X. Apparently Apple (or NeXT before them)
> decided that the arrow keys should generate character codes too.
>
> See <http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT>
> (or other pages reached from <http://www.google.com/search?q=U%2BF700>).
>
> As far as I know the SDL documentation does not specify that
> non-character-keys should not generate Unicode values, so the observed
> behavior of the Mac OS X (Quartz/Cocoa) backend seems to be OK.
>
> > So maybe I'm asking for advice: should I try to handle the
> > "command-like" non-printing characters first before anything else?
>
> That's what I do.
>
> I wouldn't spend too much work on this issue though, as the keyboard
> handling is supposed to be rewritten for 1.3 anyway, and who knows how
> this will work then.
>
>   -Christian
>
>
> _______________________________________________
> SDL mailing list
> [hidden email]
> http://www.libsdl.org/mailman/listinfo/sdl
>

_______________________________________________
SDL mailing list
[hidden email]
http://www.libsdl.org/mailman/listinfo/sdl
Loading...