Hi David,

	This sounds nice overall, especially since all morphs can be  
keymapped. As others said, if you could
	not depend on BFAV this would be even nicer. Hopefully I will have  
some more free time next month,
	so we could see together how to integrate that with services.

Cheers,
	Romain

On Sep 17, 2004, at 5:26 AM, C. David Shaffer wrote:

> I have posted a pre-release of the latest Keymapping version.  This is  
> a pre-release so that I can get some feedback on the directions I'm  
> taking this small enhancement.  I don't recommend loading it into your  
> production image.  I have been using the current version for a few  
> days now and it seems OK but I hook into keyboard event handling  
> pretty early in the event chain so problems could leave you with a  
> hosed image.  Also, it conflicts with the Keymapping release on  
> SqueakMap so don't load them into the same image.  It requires Sixx  
> and BFAV (I use the tab bar framework in that package).  The latest  
> can be found at:
>
>    
> http://www.cs.westminster.edu/~shaffer/cgi-bin/repository.cgi/ 
> Keymapping-cds.52.mcz
>    Load it then evaluate:
>    Keymap installTextMorphKeymap.
>    Keymap installWorldKeymap "proceed through the exception"
>    Open a KeymapEditor (from the World open menu) and have a look.     
> Here are some of the new things in this pre-release:
>
>    . keymaps are now available for all morphs, not just TextMorphs
>    . morphs belong to named keymap categories  (see implementors of  
> keymapCategories for details)
>        - by default a morph belongs to a keymap category corresponding  
> to its class name
>        - PasteUpMorphs belong to categories PasteUpMorph and World  
> (the later only if the PUM is a World)
>        - all subclasses of TextMorph belong to the category TextMorph
>        - TextMorphForEditView belongs to TextMorph and  
> TextMorphForEditView
>    . morph instances may have a "local keymap" (a per-instance keymap,  
> that is)
>    . keymap entry lookup works up the morph ownership chain
>    . keymapping takes precedence over other keyboard handling (more  
> later)
>    Bugs:
>
>    . I can't seem to get the PluggableListMorph to resize when the  
> keymap editor is resized. Tried lots of things, failed miserably.   
> Hints
>    would be welcomed.
>       . Loading and saving need some work.
>       . There is currently no way to load a keymap (from a stream) and  
> make it a local keymap for a specific morph.  This can be
>    done easily in code, however.
>       . It is currently not possible to delete a whole keymap  
> (category) from the UI
>       . There are many keyboard combinations which aren't correctly  
> translated by Keymapping.  Some of them b/c the VM doesn't pass
>    a distinct keyCode (under linux, for example, the home key and  
> <c-a> produce the same keycode so you can't tell the difference
>    between <c-home> and <c-a>).  In others cases it's just because I  
> haven't looked into it yet.  This will be the next bug I squash.
>
>
> Items I'm less than happy with and work to be done
>
>    . KMBlockActions are compiled in the nil context so "self" is  
> meaningless.  Not a big deal since you can get the target
>    morph as an argument to the block but creating a block with:
>        km addSequence: '<c-q>' action: (KMBlockAction block: [self  
> doSomething])
>    can be confusing in the GUI (i.e. it won't work if accepted as-is).  
>  There will also be problems if you try to load a saved
>    keymap containing this entry (KMBlockActions only save their source  
> code and are recompiled upon loading).
>       . As mentioned above, keymap entries take precedence over  
> keyboard events handled by keyStroke:.  For example,
>    the default keymap defines <m-t> to find a transcript.  If you open  
> a ProcessBrowser and try to use the terminate keyboard
>    shortcut, it will raise a Transcript instead.  This is easily  
> corrected by moving all morphs over to using Keymaps :-)
>
>    . More existing morph shortcuts need to be converted to keymappings
>       . I should revisit rr's services framework in light of this  
> redesigned package and supply a ServiceKeymapAction.
>       . Keymaps should report conflicting entries (same sequence or  
> one sequence which is a prefix of another) and there should
>    be a way to find conflicting entries in a morph ownership chain
>
>
> As always, feedback is welcomed.
>
> David
>
>
>