Ary Borenszweig schrieb:
> Frank Benoit a écrit :
>> Bruno Medeiros Wrote:
>>> The JFace Text framework in D? Pretty cool :)
>>> The ideia of having Eclipse functionality in D is pretty awesome! If we had the whole Platform available it would be ass-kicking, but it would also be an herculean effort.
>>
>> I hope some D IDE devs will pick it up to create a D IDE written in pure D. *blink*
>> What is needed from the Eclipse framework? Probably not all, and perhaps even less to start with?
> 
> How can one implement plugins in D?

I think it should be possible to use a scripting language to implement a general purpose plugin mechanism. MiniD 2 seems to be a very good choise for that task.
IMO worth to think about.

BLS Wrote:
> I think it should be possible to use a scripting language to implement a
> general purpose plugin mechanism. MiniD 2 seems to be a very good choise
> for that task.
> IMO worth to think about.

I don't think that makes sense here.
The whole eclipse platform is a set of plugins.
The plugins are using each other, without any intermediate layer. The classes are just runtime loaded.
So all plugins are written in the same language.

Frank Benoit schrieb:
> Bruno Medeiros Wrote:
>> The JFace Text framework in D? Pretty cool :)
>> The ideia of having Eclipse functionality in D is pretty awesome! If we had the whole Platform available it would be ass-kicking, but it would also be an herculean effort.
> 
> I hope some D IDE devs will pick it up to create a D IDE written in pure D. *blink*
> What is needed from the Eclipse framework? Probably not all, and perhaps even less to start with?
> 

What I miss is a docking framework. (like AUI for wxWidgets) SashForm is nice, but docking is nicer :)

Frank Benoit schrieb:
> BLS Wrote:
>> I think it should be possible to use a scripting language to implement a general purpose plugin mechanism. MiniD 2 seems to be a very good choise for that task.
>> IMO worth to think about.
> 
> I don't think that makes sense here. The whole eclipse platform is a set of plugins. The plugins are using each other, without any intermediate layer. The classes are just runtime loaded.
> So all plugins are written in the same language.

I think you are right. following osgi also means that eclipse plugin dev. guides are usefull.
bjoern

BLS schrieb:
> Frank Benoit schrieb:
>> Bruno Medeiros Wrote:
>>> The JFace Text framework in D? Pretty cool :)
>>> The ideia of having Eclipse functionality in D is pretty awesome! If
>>> we had the whole Platform available it would be ass-kicking, but it
>>> would also be an herculean effort.
>>
>> I hope some D IDE devs will pick it up to create a D IDE written in
>> pure D. *blink*
>> What is needed from the Eclipse framework? Probably not all, and
>> perhaps even less to start with?
>>
> 
> What I miss is a docking framework. (like AUI for wxWidgets) SashForm is
> nice, but docking is nicer :)

with docking framework, you mean the views and perspectives? The is the eclipse workbench plugin. We will see

Frank Benoit schrieb:
> BLS schrieb:
>> Frank Benoit schrieb:
>>> Bruno Medeiros Wrote:
>>>> The JFace Text framework in D? Pretty cool :)
>>>> The ideia of having Eclipse functionality in D is pretty awesome! If
>>>> we had the whole Platform available it would be ass-kicking, but it
>>>> would also be an herculean effort.
>>> I hope some D IDE devs will pick it up to create a D IDE written in
>>> pure D. *blink*
>>> What is needed from the Eclipse framework? Probably not all, and
>>> perhaps even less to start with?
>>>
>> What I miss is a docking framework. (like AUI for wxWidgets) SashForm is
>> nice, but docking is nicer :)
> 
> with docking framework, you mean the views and perspectives?
> The is the eclipse workbench plugin. We will see

Yes that is what I've meant. IMO this feature is a must have in order to develop a modern IDE (or something similar).

ATM I don' see why this has to be a plugin.

Bjoern, heh enjoy the weekend :)

Frank Benoit wrote:
> Ary Borenszweig Wrote:
> 
>> How can one implement plugins in D?
> 
> In theory this can be made with a DDL like mechanism.
> IMO in the first run, it can be ignored and you just compile the configuration you want.
> A dummy OSGi/Equinox API could be used, so the code is still compatible.
> 

Yeah, I was thinking the same. A dummy OSGi which only supported static configurations (ie, no runtime loading/unloading) would probably be the best way, both because a full functional OSGi framework would not be the most important functionality of the Eclipse platform to have first, and because it doesn't seem DDL is mature enough for this task.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros a écrit :
> Frank Benoit wrote:
>> Ary Borenszweig Wrote:
>>
>>> How can one implement plugins in D?
>>
>> In theory this can be made with a DDL like mechanism.
>> IMO in the first run, it can be ignored and you just compile the configuration you want.
>> A dummy OSGi/Equinox API could be used, so the code is still compatible.
>>
> 
> Yeah, I was thinking the same. A dummy OSGi which only supported static configurations (ie, no runtime loading/unloading) would probably be the best way, both because a full functional OSGi framework would not be the most important functionality of the Eclipse platform to have first, and because it doesn't seem DDL is mature enough for this task.
> 

The problem with that approach is that there are a lot of things in Eclipse that you might or might not use depending on what you do or not in a session. Eclipse loads *a lot* of things lazily, and tries to populate the UI using as much stuff from the plugin.xml files as possible. If you don't make that lazy, then Declipse will probably be as slow as Eclipse, or worse.

Ary Borenszweig wrote:
> Bruno Medeiros a écrit :
>> Frank Benoit wrote:
>>> Ary Borenszweig Wrote:
>>>
>>>> How can one implement plugins in D?
>>>
>>> In theory this can be made with a DDL like mechanism.
>>> IMO in the first run, it can be ignored and you just compile the configuration you want.
>>> A dummy OSGi/Equinox API could be used, so the code is still compatible.
>>>
>>
>> Yeah, I was thinking the same. A dummy OSGi which only supported static configurations (ie, no runtime loading/unloading) would probably be the best way, both because a full functional OSGi framework would not be the most important functionality of the Eclipse platform to have first, and because it doesn't seem DDL is mature enough for this task.
>>
> 
> The problem with that approach is that there are a lot of things in Eclipse that you might or might not use depending on what you do or not in a session. Eclipse loads *a lot* of things lazily, and tries to populate the UI using as much stuff from the plugin.xml files as possible. If you don't make that lazy, then Declipse will probably be as slow as Eclipse, or worse.

Yeah, but in the beginning D-Eclipse would only have a few available plug-ins...: the core/Platform, a D IDE, and maybe a source control plug-in. I certainly don't see any prospects of porting JDT, CDT, Mylyn, WTP, GMF, EMF, etc.,etc. to it :P
Also, with a little more developed semi-mock OSGi, the initialization could be performed lazily. Only the dynamic loading (ie, loading code) would have to performed statically to avoid having to use DDL.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D