Hi ruben

I was not clear, I was in the process of harvesting a enh of romain  
and noticed (traces of dependencies
with I do not remember which packages). And I thought that it would  
be good if all the guys
working on keybased interaction would sake a bit the interface of  
paragraphEditor or other classes and
arrive to a nice solution.

So I wanted to know if there were incompatibilities between the  
changes of romain, keymapping and ecompletion.

Stef

On 21 sept. 05, at 11:35, Ruben Bakker wrote:

> 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
>>
>>
>>
>
>
>