> Just to make sure I don't get you wrong: you're describing what *should*
> be implemented, not what's *currently* implemented (on Cocoa and X11),
> > * The physical key codes are the characters printed on the keys, if
> > they are text keys (e.g. 'A'), and the SDLK_* constants otherwise.
> I assume this is a typo and you meant to say "The layout key codes are..."?
No, I meant to say the physical key codes. The layout key codes are simply
a (potentially) remapping of values.
> One small issue I see with this is that determining the character
> printed on the key involves a bit of guesswork, while determining the
> character typed by the key is straightforward.
Fair enough, we can certainly go with the value that is typed by the key.
My concern was that this would be ambiguous for things like dead keys and
composition keys. It would certainly be more consistent with SDL 1.2.
> In your proposal, it would need to happen in SDL_GetLayoutKey().
Yes, that is pretty much what I assumed SDL_GetLayoutKey() would do.
I assumed that it would reflect key remappings like DVORAK and AZERTY.
> So, if I'm understanding you correctly, 'Q' == 0x51 appears as a
> physical key code in your proposal? In other words, not all physical key
> codes are based on the USB standard, but some (the alphabetic ones, I
> assume) are based on ASCII/Unicode?
Yes, that's what we discussed all along, as far as I know.
Hmm. Were you proposing having the codes be (USB code | SDL_KEY_MASK) ?
> What do SDL_GetLayoutKey(SDLK_KEYPAD_1) and
> SDL_GetKeyName(SDL_GetLayoutKey(SDLK_KEYPAD_1)) return?
SDLK_KEYPAD_1 and "keypad 1" respectively.
> Sounds good, apart from the points I've commented on above. Go ahead and
> implement it, I guess, and I'm sure I'll have lots of complaints about
> details that I liked better in my implementation ;).
Well, aside from details like keypad naming, I thought I was clarifying
your implementation. :)
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
SDL mailing list