On Monday 14 July 2003 08:07 am, Bijan Parsia wrote:

> This is great. One challege, I'd imagine, is to do all this without
> mucking with possible user arrangements.

Yes. You have to have a good UI to keep yourself from getting into 
baffling situations. And probably also a "panic switch" that returns 
your system (perhaps temporarily) to sane defaults.

> I'm fond of the idea, though not the execution of MrEd's keymaps:
>
> http://www.cs.huji.ac.il/support/docs/drscheme/toolbox/node1398.htm
>#classwxkeymap
>
> Especially chaining:
> http://www.cs.huji.ac.il/support/docs/drscheme/toolbox/node1403.htm
>#methodwxkeymapchaintokeymap

There's really a couple of issues here. One is separating event 
handling from event interpretation. The main problem in Morphic event 
handling is deciding what Morph should receive an event. Luckily, the 
rules for keyboard events are pretty easy: text morphs will accept 
keyboard events when they have the keyboard focus and aren't locked. 
If they don't understand a keystroke, they just drop it. You can even 
add your own keystroke (or mouse) event handler to a TextMorph or 
PluggableTextMorph.

I've been looking at Morphic event handling lately, and have come to 
the conclusion that there's not really any reason why Morphs should 
only have one callback on a particular kind of event. For instance, 
right now you can only have one eToy script that runs on mouseDown on 
a particular Morph; this is apparently because of the single 
mouseDown handler slot in the EventHandler.

We already have key translation, of course, but not key reassignment.  
InputSensor keyDecodeTable can be used to swap keyboard assignments. 
Right now it's only being used for some ctrl and alt editing keys, 
but you can use it (for instance) to swap any two keys.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE