Sorry for answering late, I just got home from a week long business trip.

I'm not sure if I understood the conversation: Is an
keymapping/eCompletion integration possible today? Or should we wait
for a newer version of keymapping and do the integration then?

Ruben




On 9/18/05, stéphane ducasse <ducasse at iam.unibe.ch> wrote:
> I checked and eCompletion requires shout.
>
> > I am going to publish a version of Keymapping for 3.8/3.9.  It will be
> > on SM in the next two hours...I hope that is soon enough for you to
> > have
> > a look.  It seems like you're having a fit of productivity right now
> > :-)
>
> :)
> I just decided to take one complete evening on harvesting...
>
> >   This release will not have the overrides for tool support so you
> > will not be able to customize the tool keymaps, for example.  This
> > is a
> > big step backwards compared to 3.6/3.7 but until an application/tool
> > framework develops I don't want to maintain my overrides.  I see the
> > 3.6/3.7 version of Keymapping to be "proof of concept" that we can
> > have
> > completely customizable keymaps for our tools.  Services takes this
> > one
> > step further so hopefully it will emerge as the solution.
>
> Ok you mean that with keymapping 3.8 we cannot customize the browser
>
> > If the long-term intent is to keep these out of the "base" image
> > then we really
> > need to spend time to make the current tool framework more
> > introspective
> > for add-ons such as Keymapping and Services.  I would rather see them
> > both in the base, though, and will do whatever I can to help.
>
> I would like to see them both in base but managed as package (may be
> not for services).
> I did not check all the code but something with no extra classes,
> classes commented,
> would be nice. I think that having the possibility to have per morph
> different binding
> is important. May be we should have a design more driven by interface
> to be able to
> plug an idiot keymapping (= default one) or a full one (keymapping).
>
> Stef
>
>