There is a very simple navigator on the left, a thumbnails view, and a preview area.
As I wrote the application based on Eric's and Tom's work, I started by implementing a couple of views that I contributed to the new e4 Workbench through an extension point.
Then I realized that all I need is an EMF model representing the parts that make up the UI: the views, the menu, and the toolbar. I don't actually need any extension points, because my application is not an extensible IDE - it is a rich client application for which I know how the UI should be structured. I am pretty happy about the end result - my application is fully described by one XMI file that I can edit using an editor for EMF models, and I can just go and modify that file if I want to rearrange views, add new ones, delete unnecessary ones, build my menu structure and so on.
Compare this to how it works with the current 3.x Workbench: I would have to write a perspective extension, a couple of views extensions, a command extension, a menu and a toolbar extension. Then I would have to assign unique IDs to all these pieces, and to ensure that IDs match up properly. How many hours we've wasted in the past when IDs did not match up!
Of course, this only works for closed applications, not for open and extensible ones like e.g. the Eclipse IDE. However, it is still pretty useful to be able to reason about a concrete EMF model representing the UI application structure. For example, when you have lots of little pieces contributed by many plug-ins, we can now talk about what it means to produce that concrete model from the many little pieces. One interesting question based on this is: Can we maybe generalize the many ad-hoc mechanisms we have grown over the last years (most of which involve matching up IDs) to something that is less ad-hoc and more general?
It's been fun to work on this little application so far. If you would like to participate, let us know on the e4 mailing list, and/or attend the bi-weekly e4 conference calls. You can always email me directly, of course.
P.S. The code is available in CVS - check out the ui/demos project under /cvsroot/eclipse/e4-incubator to get the launch configuration and project set file (emf-workbench.psf).
Posts
3 comments:
I wonder if the choice of pictures in the demo is an (un)conscious nod to Ed :)
Is using this model driven approach the only way to design e4 RCP apps? I somewhat would not like my MODEL to describe how the VIEW looks like. Or I misunderstand the concept here.
Also I found that EMF drags in to many dependencies into apps and bloats them. Till this day an Eclipse RCP was reasonable small in download and runtime size, however all the required plugins for EMF will increase the deployment size, will it not?
The current model of specifying the model via plugin.xml declarations will continue to work as always. Regardless of how it's done, there always has been and will continue to be a model that underlies the concepts for how the IDE is organized once all the declarative data is read in. The idea is to make it explicit.
EMF drags in no additional dependencies and works stand alone with no additional dependencies, not even Eclipse ones. Generally you can get by with just EMF's core runtime plugins, where only the first two are strictly needed to prop up the model (and it's certainly possible to produce stripped down "micro edition" runtime in the 500-600K range.)
187,370 org.eclipse.emf.common
1,034,902 org.eclipse.emf.ecore
80,260 org.eclipse.emf.ecore.change
216,638 org.eclipse.emf.ecore.xmi
I've seen time and time again that while people are happy to build new things to solve old problems in an effort to avoid bloat. The actual end result more often than not is that the final applications end up with a lot of different solutions to the very same problem. I.e., the approach of avoiding the bloat literally ends up causing the bloat.
Actually avoiding bloat requires coordinating the different aspects of the overall solution with a focus on reuse. There will definitely be a focus on reducing bloat in e4.
Post a Comment