Community
Participate
Working Groups
When refactoring Zest and GEF (MVC) it has be ensured that both frameworks become directly usable in the context of the new Eclipse 4.x Application Platform (without having to stick to the 3.x compatibility layer). While there might be additional issues involved, this at least implies that those parts of the current code base, which have direct dependencies to the Eclipse 3.x Workbench API, are cut free and transferred into separate plug-ins.
Any update on this work?
Is this still planned?
Yes it is. However, we are not yet at a point where we can replace/migrate GEF (MVC), where this will then be an issue. Up to now, we are concerned with migrating/replacing the Draw2d and Zest related parts of GEF. You can find further information on the wiki pages: http://wiki.eclipse.org/GEF/GEF4.
As demonstrated by the standalone examples we provide for MVC.FX and Zest.FX, both frameworks can be used even outside of the Eclipse UI. As such, direct usage within the Eclipse 4.x Application Platform should actually be possible. We should investigate whether we should provide (a possibly very thin) integration layer as we currently do for the 3.x workbench, or whether that is not needed (because everything could already be performed via respective bindings).
Some update on this one: The org.eclipse.core.commands dependency of the MVC, MVC.FX, and Zest.FX bundles seems to be the only one from our standalone bundles to a bundle contained in the compatibility layer. To achieve the pure e4 integration goal, we would thus at least have to investigate, whether this dependency could be replaced with some pure e4-based counterpart. The MVC.UI, MVC.FX.UI, and Zest.FX.UI bundles, which realize the Eclipse integration for the MVC.FX, MVC.FX, Zest.FX bundles in addition specify dependencies to org.eclipse.ui, org.eclipse.ui.views, and org.eclipse.ui.workbench (Zest.FX.UI only), which seem to be part of the compatibility layer as well. IMHO this seems to be tolerable as a starting point (pure e4 applications would have to avoid them).
The 'org.eclipse.core.commands' is not part of the compatibility layer, instead it is used in Eclipse 4 Applications directly. Its only dependency is 'org.eclipse.equinox.common'. Have a look at 'org.eclipse.e4.ui.internal.workbench.addons.CommandProcessingAddon' from 'org.eclipse.e4.ui.workbench', which consumes commands in the model (from ECommandService) and feeds them into the core command service (CommandManager). By the way, JFace also depends on 'org.eclipse.core.commands'. Apparently MVC, MVC.FX, and Zest.FX can be used in pure Eclipse 4 Applications.
Thanks for clarifying this, Alex. That means we will only have to investigate, whether the UI-integration we provide can be adopted to use pure e4 mechanisms.
An e4 port of the MVC logo example has been produced as of bug #491750. We can probably infer from it, how the UI integration could be adjusted (if required at all).
