Whole other debate on keyboard mappings

Ian Piumarta ian.piumarta at inria.fr
Thu Jun 6 19:50:43 UTC 2002


Guys,

["who wrote what and when" deleted, since I'm just airing my angst and
not in any way, shape or form reacting to any particular personal
position.]

> > > > Surely this is all something that should be tackled im the image with a
> > > > sensibly configurable keymap
> > > First, images should remain portable -- let's not end image portability
> > One could add a trivial extension to check for an external file
> > to provide for user local overrides.              ^^^^^^^^^^^^^
               ^^^^^^^^^^^^^^^^^^^^^^^^
This is The Correct Solution.  The "event mapper" (or whatever) in the
image should read the per-user prefs file to figure out the
(image-side) keyboard mapping.  That way _any_ image, downloaded from
_anywhere_, running under _any_ VM, on _any_ platform, will work the way
the user expects.

(This doesn't address the "out-of-the-box" issue though, which I still
maintain is best handled by a combiation of _strongly_ suggesting to
first-time users that they RTFM and by providing them with a _trivial_
mechanism to make things [read: their choice of key to use for
"cut/copy/paste" in Squeak] work the way they like in the context of
their local hardware's [possibly significant] peculiarities.)

> an appropriate SystemDescription object available, though, doesn't it?

Not necessarily, since (as the same author points out later on)...

> Also there's the whole "virtual machine" strategy.  It's nice if the
> image sees the same sort of machine no matter what platform you are

...which implies system-specific stuff be taken care of in support
code, not by some image-side platdep configuration object.

(Which, FWIW, in the context of the "real" problem under discussion
here [see below], would require this object to contact the X server,
ask it about its modifier map, decode the information recieved [and
maybe ask the user about {or execute the famous RPM "read programmer's
mind" insn via the OSProcessPlugin} the physical layout of the
keyboard].  I don't think anybody wants things to come to that.)

> I agree!  There can be a project or module on every system that has
> platform-specific stuff at the image level.

Isn't it easier just to read a teeny little .squeakkeys file somewhere
in the starup list?

> Unfortunately it will open the floodgates for ever more
> platform-specific stuff.  :)

To be avoided at all costs.

Like someone already said: the "nice thing about the vm model" is that
(to the image) everything works the same on all platforms.  (The "dir
delimiter thing" is an ugly aberration that we are, unfortunately,
probably stuck with for the foreseeable future.)

> Well it's true you can't fiddle with it easily.  Not that all that
> many people would do so.

We're kind of missing the original point of this thread.  Let's back
up a little.

The debate is not really about which *squeak* modifier key does what
inside the image, which can (and should) be per-user configurable
using Ned's "event and kitchen sink remapping utility".  But this has
nothing whatsoever to do with the modifier problem in the *VM*.  The
real question is how to cope with keyboards that have different
numbers of (and different placements/labels on [and X servers that map
different indices {in different OSes and/or even different server
releases} to the]) "alt/meta/opt/apple/flower/command/diamond/stupid-
little-flying-window" key(s).

> But it's also true that no time or effort or storage is necessary --
> there already has to be a mapping, anyway.

Strike one!

(The mapping exists only because [compared to X11] Squeak has
different mask indices for its modifier bits and confuses shift with
lock into a single bit, and because we need to [find and] map a
suitable "meta" key [in a _highly_ ambiguous context {et voilà
l'essentiel du problème, mes chers amis}] to Squeak's "command"
modifier.)

> It seems like we may as well go ahead and translate in the fashion
> appropriate for the platform.

Strike two!

(We do that already anyway: Most people have CTRL and SHIFT keys -- so
these are definitely not the problem.  The problem is which of the
"alt/meta/opt/.../dumbass-flying-window" keys should get mapped to
Squeak's "command" key on platforms that DO NOT HAVE a Command key.
[Unfortunately this is now a problem *even for people who have a
Command key*, since the infinite wisdom of XF86.org drove them to
change the mod map index of this key on Apple keyboards in the
last-but-one minor release.  Plus there's no guarantee that
joe.hacker at kernel.org {who has never even touched an Apple keyboard}
won't one day decide to change the raw keycode assigned to the Command
key in Linux {because it "just wasn't poetically correct"} which
instantly hoses the server, regardless of any internal consistency
problems it might have.])

> Especially since the canonical form is imaginary anyway.  Why
> translate alt to command -- which doesn't even exist on a PC
> keyboard -- and then translate command to control in the image?  The
> VM could just as easily translate alt to control (or whatever)
> directly.

He's out!

[Someone of the American Persuasion will have to correct me if I
inadvertently missed a "Strike three!" somewhere back there.]

(All of this is completely irrelevant to remapping according to user
preferences, which should happen _inside_ the image and be configured
_outside_ the image [in the prefs file] and in no way implicate the VM
itself whose only [single {_unique_}] problem is this: "how do I
choose an X11 modifier index [amongst 5 possibilities, one of which is
almost certainly already assigned to NumLock and the others _randomly_
assigned to _random_ keys in _random_ physical locations] to map to
Squeak's "command" modifier bit?"  [And the fact that mapping Alt to
this bit is correct in maybe 70% of the cases {i.e., for Linux kernels
on PC-compatible hardware} is of little consolation to people like
Richard {or anyone using Apple hardware like myself} who have both Alt
and Meta keys {or _real_ Option and Command keys} and who desperately
want mod1 mapped to Option and mod4 mapped to Command such that the
meaning of the modifiers relative to the physical location of the keys
is identical between Squeak+Solaris+Sun keyboard and Squeak+Mac+Apple
keyboard.])

Anyway, all this is probably academic since (with a little off-list
help from various people using various combinations of OS/system/X11
vendor/version) I think I've come up with what might just be the Final
Solution that weakends the strain [on mapping-related humour].  (For
memory misers: it costs 8 bytes in data and maybe 50 insns in text.)
It's already in 3.3.1 which (if I ever stop spending so much time in
demented rantings) will be available in a few hours' time.  (Added
bonus: it also fixes the problems on Mandrake systems which [according
to a colleague at work who uses it -- and exactly as Lex already
suspected] really _is_ severely broken].)

Tchao,

Ian




More information about the Squeak-dev mailing list