Hi folks,
some of our Mac OS X users are having problems with ScummVM <http://
www.scummvm.org> running on a machine with an AZERTY keyboard, a
layout that is standard in many french-speaking countries (France and
Belgium for example). The tricky thing about that keyboard layout is
that in it the “number row” differs considerably from that on a
QWERTY keyboard.In particular, the key which “normally” is labeled
"1" instead is labeled “&”, and to get a “1” you have to press “Shift-
&”, i.e. the opposite of a what happens in “normal” keyboard layouts.
To see what I mean, see here: <http://en.wikipedia.org/wiki/AZERTY.
Now, we offer our users certain hotkeys, among them are the Ctrl-
NUMBER and Alt-NUMBER hotkeys (for quick saving/loading). No issue,
you might say now – just use the keysym and be done with it, it
should return “1” for that key on AZERTY, too.
However, this is not the case on Mac OS X, due to some “clever” code
which tries to correct the default hard-coded keymap to accommodate
for non-US keyboards. The idea for adding that code back then (I was
involved in that) was to compensate for changed letter key positions
on non-QWERTY keyboards. For example I am using a QWERTZ keyboard
where y and z are swapped. That code in the Mac OS X variant of SDL
makes sure the keysyms for these two keys are swapped, too.
Why doing so? Because the purpose of keysyms is not completely well-
defined in SDL (and I think Sam is aware of that and maybe 1.3 will
improve in that regard). There are two different roles it tries to
support: One is to represent the symbol that is printed on the key
(which is what the OS X port currently tries to do). The other is to
represent the “position” of the key (so you don’t care whether the
key between “t” and “u” is labeled “y” or “z”, you you always want
SDLK_y, meaning “the key between t and u”).
Both functions have their merits, depending on what you are trying to
do, I guess… But at least for AZERTY keyboards, the fact that
pressing the “& resp. 1” key generates not a SDLK_1 keysym, but
rather SDLK_AMPERSAND. As a result, the above-mentioned quick save/
load hotkeys don’t work for those users. (see also ScummVM bug report
#1643848, “MACOSX: Unable to save/load using numbers on AZERTY
keyboard”, <https://sourceforge.net/tracker/index.php?
func=detail&aid=1643848&group_id=37116&atid=418820>)
My question now is: How should I resolve this “best” ? Several
possibilities come to mind. But I am not sure which to choose, and
maybe I am also missing some possible solutions. Finally, it would be
interesting to know how other SDL ports (e.g. on Windows on Linux)
behave in this regard, to make sure we get uniform behavior across
ports). My ideas so far:
-
Do not remap the keysyms for the keys in the number row, like “1/
&”. The attached patch does that. It’s simple, but is it “the right
thing” to do? Are there maybe keyboard layouts where this produces
bad results? Is there any code that will suffer from it -
Don’t perform any of the “remap to try to accommodate for
international keyboard” voodoo, i.e. get rid of the “KCHRPtr” code in
src/video/quartz/SDL_QuartzEvents.m -
Call SDL’s behavior “correct” and somehow fix the problem inside
of ScummVM. Maybe by allowing the user to define a custom remapping,
defining “quicksave to slot 1” as “Alt-&” -
Tell our users to use Ctrl/Alt+KEYPAD – although of course not
all machines have a numerical keypad -
… ? Your idea here
Cheers,
Max
-------------- next part --------------
A non-text attachment was scrubbed…
Name: macosx-azerty-fix.patch
Type: application/octet-stream
Size: 706 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070627/ae79fda6/attachment.obj
-------------- next part --------------