JPz'log Coin Coin and Plop da Plop

Building a GEF-based Eclipse editor – part 0

This entry is the first one of a serie which will aim at showing how to develop a GEF-based Eclipse editor plug-in. I introduce here the context of this serie plus some discussion on the technology choice.

This plug-in has been developped as part of my research work and the first feature-complete release looks like this:

This serie will present you the following interessting features:

• developping a GEF based editor
• supporting an outline view linked with the editor
• supporting a properties view linked with editor to allow for editing the displayed elements.

First of all, it might be useful to justify the choice of Eclipse and GEF. As a researcher,the software that I can happen to develop is about prototypes. This means that I care about showing an implementation of my contributions, not about developping a commercial-grade application from scratch. This is a common pitfall in the academics areas: people tend to often develop big applications every time they want to show their contributions, leading to (but not limited to):

• loss of time on developping the whole application infrastructure (UI framework, preferences support, ...)
• the contribution code (i.e. what is really innovative) tends to be much too coupled with the application
• difficulty to integrate several contributions in a single project.

Eclipse allows for solving these problems in a very elegant way. Indeed, it provides a framework to develop loosely-coupled (yet integrated !) components without having to worry about the whole infrastructure. As I said before, I am interessted in implementing my contribution, the rest is a loss of time for me. In this vision, one contribution means a set of plug-ins, grouped together in a feature. To enforce the decoupling of the components, I also extract the core of my contribution as an independent library which first lives inside a JUnit environment. Then I can wrap this library as an Eclipse plug-in and start developping UI-related plug-ins that will depend on the library wrapper. Fellow researchers can also develop their contributions this way and we can easily put everything together. Herecomes the beauty of the Eclipse platform: the day we want to provide a specialised environment with our contributions, we can either brand our own Eclipse IDE or take our features and put them on topof Eclipse RCP. Ice on top of the cake: Eclipse is released under a smart open-source license.

In my situation, I needed to implement a graphical editor for a given model. I will not elaborate on this as it is not the point of this serie. Basically, you can see this as some kind of transition systems (automata theory). This is graphically translated to states and relations between the states. GEF is a very nice MVC framework. It has the big advantage of beeing really model-agnostic. You can plug anymodel that you have developped before without beeing worried about having to develop some silly model adapters just to use a given graphical framework. This genericity does not make GEF very complicated because it has been really well tought. The major drawback of GEF is the documentation anyway. It is very difficult to get started with just the provided documentation since it consists of Javadocs with a few diagrams which don't help much unless you already know how GEF works. The few tutorials that you can find online are not that helpful either. The best option is still to have a look at the examples. This is the main reason why I wanted to write this serie: provide a progressive hands-on introduction to GEF. I hope to succeed at this and that it will help some people getting to grips with this smart framework

One last point (to step out from the Sun propaganda versus the IBM propaganda): I know that Java2D is quite efficient now and that Swing applications can look good if you are a talented guy like this one. I also know that Netbeans is supposed to have been a RCP platform before Eclipse gained the hype. The fact is still that Eclipse makes my life much easier and you don't see that much stuff built on top of Netbeans technology. I won't feed the troll since debating wether Eclipse/SWT is better than Netbeans/Swing is a huge loss of time (both have their pros/cons), but consider me as beeing more on the IBM side. So please don't bother me with such considerations. If you really hate Eclipse-related stuff like SWT, please click the browse back button of your web browser and keep beeing a so narrow-minded whiner. For the other people, feel free to provide interessting comments and show me when there exist a better way to do things or when I am simply wrong

Stay tuned for the next entry.

Related posts:

1. Building a GEF-based Eclipse editor – part 3
2. Building a GEF-based Eclipse editor – part 1
3. Building a GEF-based Eclipse editor – part 2
4. Eclipse 3.1 M5
5. Netbeans as a J2EE teaching IDE