Re: [ease-dev] [eclipse-scripting-dev] EASE vs Eclipse Workbench (e4 or

[James Watkins-Harvey <jwatkins@xxxxxxxxxxxxxxx>]

James, which UI components do you have in mind? Currently we have the shell, script explorer, model explorer and a partly implementation of toolbar and menu contributions. These things are already in place, so I would not re-implement them as long as there exist no radical ideas for features that can't be done with the 3.x mechanisms.

Indeed, and no, I’m not actually considering re-implementing the whole thing. Right now, I am mainly replacing « code »  by « plugin.xml contribution items »  whenever it makes sense, notably in commands, handlers and popup menus construction, because I am under the impression that a lot of unresolved bugs actually lurks around there, and because internationalizing and homogenizing the look and feel of the plugin will be much easier this way.

Personally I think that the UI capabilities of e4 are a nice to have, but do not bring much benefit.Instead I would love to implement the event broker for all kinds of messaging and to get rid of the listener concept. No more listeners for script engine creations, code executions, scripts registering for the Script Explorer... that would be nice. Still event broker means e4 exclusively.

     The e4 model for views with DI and its styling capabilities is quite nice, but so far e4 was lacking one crucial feature: to define view extensions that work without knowing your application model. I know there have been some efforts to make this work with Luna, yet I am not aware of the current status. As the scripting components not only target the Eclipse IDE itself, but also users RCP applications we should not have any hard dependencies to the e4 workbench application model.

My question was more about a direction to strive for. For example, while going through command handlers, should I convert them to e4’s behaviour annotations rather than extending AbstractHandler? On that matters, DI is really the principal feature that seems to be interesting, and, I agree, that’s not that much. Still, given what had been said previously, what I had in mind was to « split » each handler in two classes: the main one in DI style, and the second, a thin wrapper in traditional e3 style, that gather arguments and provide them to the main DI-style handler. That’s basically the way the e4-bridge work. Still, at present time, I think that all of Ease’s UI contributions should still be provided using e3 extension points, simply because properly converting the whole plugin to e4 would require too much effort at this time.

So really, what I am saying is that some e3 UI components would coexist with some e4 UI components, the latter being wrapped to behave as if they actually were e3 components. Over time, all e3 components will be converted to the e4 + e3 wrapper model, and then, e3 wrappers will be moved to a compatibility plugin, and transitioning to the e4-only contribution style will then be considered. But this is far ahead.

Does that make more sense with you? Anyway, there is really no rush on the subject. At this point I have only done pure-e3-style modifications to ease projects, of which I will commit a first draft some time this weekend, and there is no problem in maintaining that direction until the matter is properly decided.

James Watkins-Harvey

Software architect and Research and Developement director

www.progi-media.com