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.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Re: Meaning of SDLK_* - undocumented and inconsistent behavi
Christian Walther
Guest

Sam Lantinga wrote:
Quote:
After working with World of Warcraft's code, I figured out how to do it
the way I had always intended, which is to map to the unshifted code for
the current keyboard. Unfortunately, this leaves SDL's keysym set lacking,
and this can't be addressed until a major API change (1.3)

I'm not sure what you mean by "the unshifted code for the current
keyboard". Is it what I called option 1 (a code that identifies a
specific position on the keyboard) or 2 (a code that identifies the
symbol printed on the key cap)?

If it is 1, how does that leave the keysym set lacking? It seems to have
codes for all keys of all keyboards I know. And even if some would have
to be added, why would that cause API incompatibility?

Quote:
To answer your question, it should generally be option 2, specifically
so those programs which make that assumption (almost all emulators) will
work correctly.

Is that so that "almost all emulators" make that assumption? AFAIR,
Qemu, Basilisk II, and PearPC use event.key.keysym.scancode and map it
to a platform-independent position code using platform-specific look-up
tables. If we changed event.key.keysym.sym to be such a code everywhere,
they could stop doing that. As they aren't using event.key.keysym.sym at
all in their current versions, there would be no backwards compatibility
issue for them.

Also, since the DirectX backend currently implements option 1,
applications that assume option 2 don't work correctly there already.

I'm not sure if in "almost all emulators" you include those whose
emulated devices don't have a PC-style keyboard, but for those it
doesn't matter much IMHO as their PC-key-to-device-key mapping is
arbitrary and should be configurable anyway.

-Christian