GMFTools Part 1: UI Extensions

This is the first of a short series of posts on GMFTools.

The Graphical Modeling Framework is a powerful framework for the development of graphical editors for EMF-based models. It's based on EMF and GEF and uses a model-driven approach for designing the editors.

Building graphical editors is a complex task. While GMF tries to facilitate that procedure, its abstractions are sometimes still a little hard to grasp, and the generated results often need manual fine-tunig to meet end-user expectations. I am a user, not a developer of GMF. Mymain concern is getting things done in the projects I am working on. That's why I sometimes bend GMF to do what I want it do, rather than use it the way it is meant to be used. That fact makes it somehow hard to contribute back to the GMF project. Still, me and my colleagues take a lot of benefit from using GMF.

GMFTools

As a long term user of GMF, I started to collect code, tools, samples and several tipps and tricks in the GMFTools project about a year ago. In the meantime, the project has attracted additional committers and it has become quite a useful collection of real-world solutions around GMF.

GMFTools roughly consists of three components

• UI-Extensions making GMF easier to use.
• Runtime extensions that add new functionality by means of additional classes and generator template changes.
• Examples demonstrating the use of the runtime extensions.

The GMFTools Button

The first thing that may catch your attention after having installed GMFTools is a new GMF button in your button bar. It is meant to make GMF development easier and performs a bunch of actions on your GMF projects, including running the GMF code generator. To see what kind of actions, open the preference page for GMFTools. Each action can be enabled and disabled separately.

Most of the actions are self-explanatory. You may wonder why I want to delete the gmfgen model and the diagram code before re-generating. The reason is that by deleting the generated artifacts before re-generation, I circumvent all reconciliation steps (including JMerge). I have very bad experiences with reconcilers in general and so I prefer not to mix manually written and generated code. Some people have called me a "purist" for this attitude, but from my experience a clean separation will pay in the long run of a model-driven project.

As a consequence gmfgen model becomes a temporary artifact in the whole code generation procedure. To be able to modify the gmfgen model nevertheless, I have introduced a model-to-model transformation that is performed before generating the actual diagram code from the gmfgen model. This transformation is performed using an Xtend file (both oAW and M2T work) which is persisted next to your GMF design models.

The fix of the type registration will be covered in a post on shared editing domains.

In the middle of the preferences, you can manipulate your current set of GMF models (might not be the best name), i.e. the combinations of ecore, genmodel, gmfgraph, gmftool and gmfmap models you need to generate a GMF editor, as well as the Xtend transformation. These sets can also be provided by means of *.def files that can be stored in your workspace next to the design models.

By a single click on the GMF button, all enabled actions are executed on the currently / last selected models. In its drop-down menu you can access all your editor model individually. That really speeds up GMF development significantly, as you no longer have to find your way through the popup menus of different files. Nevertheless, individual actions can still be executed from the popup menus of the respective files.

That's all for today. Stay tuned for more.