On Fri 19 Feb, William O. Dargel wrote:

> This all seems to point out the need for a more general overhaul of how keys get mappe
> d to
> commands. We should be able to handle all the platforms _and_ user preferences for key
> mappings by at most plugging in a new (or modifying the current) table of key-bindings
> . And
> it would of course want to interface cleanly with getting events from the OS rather th
> an the
> current polling method, and be dynamically reconfigurable ala menu accelerator keys as
>  your
> context changes, and...  But perhaps I digress.

I thought it would probably be something like that which caused your
changes. Yes, you're right, key input needs an overhaul to be more platform
portable. At the moment, everyone except Mac has complicated code to
translate from native to 'best I can work out what is needed to match'.

An idea Eliot came up with a _long_ time ago was to pass in the raw native
key values and have a small hierarchy of SystemDescription classes that had
nice intelligable code to translate to Smalltalk events. It had the big
advantage that no VM fixing was needed, that new keymappings could be added
and so on. IIRC the classes also encapsulated which file related classes
needed to be active, how external calls where done etc. Very useful.

Now if you mix that with the startup file idea where a file is looked for
and if found, filed in to do some startup work, we could simply have
platform specific files with the SystemDescription (and maybe even personal
preference settings?). And it should probably be binary streamed through
FrootLoop :-)

tim

-- 
Useful random insult:- A prime candidate for natural deselection.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>