stéphane ducasse wrote:

>
> Hi david
>
> Yes I would like to have keymapping as an official full package. So 
> this is
> excellent that you clean and revise your package.
>
> Now I need feedback on the following wish that is going in my mind.
> ***Ideally*** I would like that basic Squeak could work without 
> keymapping UI or extra stuff.


Yes, I think that this is ideal.

>
> What is the *minimal* stuff that we can put in basic that would put 
> in place
> the architecture to replace the old paragraphEditor table and that 
> could be used
> by keymapping in full.

As a first step one can look at the only two overrides in Keymapping
(for 3.8) below.  This doesn't get us too far but it makes Keymapping
pluggable and removes overrides (which really irritate me).

Morph>>handleKeystroke: anEvent
    "System level event handling."
    KeymapManager debugEvent: anEvent message: self printString.
    anEvent wasHandled
        ifTrue: [^ self].
    self allowsKeymapping ifTrue: [self dispatchKeystrokeToKeymappers:
anEvent.
    anEvent wasHandled
        ifTrue: [^ self]].
    (self handlesKeyboard: anEvent)
        ifFalse: [^ self].
    anEvent wasHandled: true.
    ^ self keyStroke: anEvent

and

TextMorph>>handleKeystroke: anEvent
    "System level event handling."
    | pasteUp |
    KeymapManager debugEvent: anEvent message: self printString.
    anEvent wasHandled
        ifTrue: [^ self].
    (self handlesKeyboard: anEvent)
        ifFalse: [^ self].
    self allowsKeymapping
        ifTrue: [self dispatchKeystrokeToKeymappers: anEvent.
    anEvent wasHandled
        ifTrue: [^ self]].
    anEvent wasHandled: true.
    anEvent keyCharacter = Character tab
        ifTrue: ["Allow passing through text morph inside pasteups"
            (self wouldAcceptKeyboardFocusUponTab
                    and: [(pasteUp := self
pasteUpMorphHandlingTabAmongFields) notNil])
                ifTrue: [^ pasteUp tabHitWithEvent: anEvent]].
    self keyStroke: anEvent


Note that (ignoring the debugging code) the check "self allowsKeymapping
ifTrue: []" basically wraps the Keymapping specific code.  So if the
base image included (in Morph):

allowsKeymapping
    ^false

and then invoked the (unimplemented) method
dispatchKeystrokeToKeymappers: as I do above my package would only have
to add that method to Morph.  If we wanted a registry model we could
implement dispatchKeystrokeToKeymappers: as

dispatchKeystrokeToKeymappers: anEvent
    self registeredKeymappers do: [:each | each
dispatchKeystrokeToKeymappers: anEvent for: self]

where registeredKeymappers answers the collection of all registered
keymappers (do we really need to support multiple mappers?):

registeredKeymappers
    ^self class registeredKeymappers

and then the obvious Morph class side methods (and variable) to register
them.  When my tools are loaded I'd register and off we go.  Want me to
submit a changeset against 3.9a for your consideration?

>
> Does this idea make sense?
> I think that this is important to work at the infrastructural level, 
> following the way
> the filelist got services for tools to register themselves.
> This is why we will push the services-kernel of romain so that all 
> the browsers
> can be enhanced by functionality by new tools. I think that this is a 
> good way to support
> extensibility and modularisation.


I'd like to comment on this further but have to step out.  I think what
we're talking about is a good first step though.  It doesn't really make
Keymapping "pluggable" but it does get rid of overrides and makes it
optional (with KM you'll just get the ParagraphEditor shortcuts).

>
> Now my question is can we make such infrastructural changes in 
> layered form so that
> the minimal can be push down and the rest stays at the full level?


See sugestion above.

David