Whole other debate on keyboard mappings

Tim Rowledge tim at sumeru.stanford.edu
Thu Jun 6 16:38:44 UTC 2002


"Lex Spoon" <lex at cc.gatech.edu> is claimed by the authorities to have written:


> > Surely this is all something that should be tackled im the image with a
> > sensibly configurable keymap
> 
> A couple of people are suggesting this, but let me disagree here. 
> First, images should remain portable -- let's not end image portability
> just to have different key mappings.  I'd hate to download a windows
> image from someone and have it use control instead of alt.
There is no need at all to have to do this and it's not at all what I
was proposing.

For BrouHaHa we implemented a very simple and effective mechanism that
was completely portable. As part of the startup sequence (though I kinda
hate to add anything more to the ludicrous amount of cruft in the squeak
startup dance) the platform ID was checked (we already do that for
filedirectory et al.) and the appropriate SystemDescription object
installed. This encoded the right filename class, keyboard map, external
interface class and some other stuff I think, in a quite intelligable
manner. One could add a trivial extension to check for an external file
version to provide for user local overrides.

Come to that, it surely ought to fit into a module world quite nicely.
Choose the platform appropriate module during startup.

> Second, this
> is trivial to do in the VM: the VM's already have a mapping from keys to
> Squeak modifiers, and we can easily set those mappings to anything we
> like.
But we can't easily change them to suit personal taste and it's simply
something I don't think a VM should spend time and storage on.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: PDH: Page to Disk for the Hell of it




More information about the Squeak-dev mailing list