Eclipse Diagram Editors From A User's Perspective

I believe that the Eclipse's diagram editing frameworks have a lot to catch up when it comes to usability. For illustration I've created a screencast on how a typical Eclipse graphical editor appears to a user. I have used the Ecore Tools editor as an example, but most issues presented are caused by defaults of GMF or GEF which are pretty hard to change. So don't be surprised if you re-encounter these or similar issues in Graphiti, Sirius etc. The screencast doesn't even cover the rendering errors described in my previous blog post.



So what has gone wrong?

In my opinion, diagram editor behavior and editing metaphors haven't really changed since the first commits on the GEF project in 2002. Advances in UI design and usability have had almost no priority on Eclipse's graphical frameworks since then. They were built from a pure developer's perspective. So a lot of effort has been spent on:

• Facilitating the development of new editors. This usually causes a restriction to very specific use cases. 
• Establishing weird processes to implement new diagram editors. 
• Repeatedly putting new abstraction layers on top of the existing ones. Hide the seemingly ugly or incomprehensible concepts of a base framework. The problem is to find better abstractions that don't leak. In the end you often have to learn both (or more) frameworks in order to use them. 
• Building on top of existing frameworks with serious limitations, like integer coordinates, missing alpha channel, no hardware acceleration etc. 
• Supporting very large diagrams. Yes, there are very big models. But diagrams with hundreds of nodes and connections only make good wallpapers.
• Creating new compatibility APIs, e.g. to replace the rendering engine. These will limit the available functionality to the common minimum set of features of all backends. 
• Changing a model graphically. Note the difference between editing a diagram – e.g. to make it look nicer – and changing the underlying model. Did you ever wonder why GEF Zest is the only Eclipse diagram framework with its own diagram layout algorithms and basic support for multi-touch gestures? 

Computers don't need diagrams. Diagrams are for humans. Their strength is to explain a part of a model in a very suggestive way. Taking the human user into focus changes the requirements for a graphical framework drastically. Issues like the following must have top priority:

• Appealing visual design, 
• Intuitive editing metaphors, 
• Snappy behavior, 
• Support for modern input devices, and 
• The possibility for individual customization. 

How do we get there? Attend my talk Eclipse Diagram Editors - An Endangered Species at EclipseCon Europe for some propositions and an extensive demo.

Obi-Wan at the Edge

There are two hard problems in computer science: cache validation, variable substitution, and off-by-one errors.      (unknown source)

The uncounted latter is often referred to as OBOE or, with a geek sense of humor, "Obi-Wan error".

Obi-Wan In Eclipse Diagram Editors

In an older post, I already mentioned one major weakness of GEF (3.x): All coordinates are integers. One problem with that is that it can easily result in off-by-one rendering bugs. That unfortunately holds for many frameworks built on top of GEF. Have a close look at the gradient fill, anchor points (where connections are touching the nodes), clipping bounds and the arrow head in the following screenshots from the standard examples:

Integer vs. double coordinates is comparable to raster vs. vector images. While in integer coordinates a point usually means a pixel, in double coordinates a point has no area and a line can be infinitesimally thin. In a world of double precision it is obvious that we need some rendering. We are forced to think about things like line width, stroke type, line caps, line joins, miters, etc. There are excellent explanatory pictures on these in the JavaDocs of JavaFX's Shape class.

"Smooth" Curves

You have to take round-off errors into account when approximating smooth curves (splines) with integer polylines. Otherwise your allegedly smooth curve will go zigzag. This might be the reason why GEF does not have any curves. GMF does:

 

Arrow Heads

I'd expect an edges arrow head them to be aligned with the tangent of the edge at the anchor point. For polylines this is the line connecting the anchor with the last bendpoint. Same for Bézier curves, but apparently not for splines like these:

  

It is also a good idea to prohibit bendpoints too close to the anchor: The inclination of the curve may become too steep:

The last screenshot also shows that the line cap style plays a role at the tip of the arrow head.

 

Use the Force

GEF 4 will have double coordinates and Bézier curves. But at the time of writing this blogpost, there hasn't been an official release yet. It is not clear either whether and when it will be adopted by downstream projects.

I came across all this when trying to calculate edges and arrow heads for my sparetime JavaFX diagram editor project. Luckily, JavaFX uses double coordinates only. JavaFX also includes quadratic and cubic Bézier curves. These curves are really smooth and drawn fast, though I must admit I'd  have expected B-Splines at least.

I am going to demonstrate this at EclipseCon Europe 2013. Stay tuned for more.

GMFTools Part 2: Sharing an EditingDomain

In this blog, I will elaborate on how GMFTools facilitates to share the same instance of an EditingDomain across multiple diagram editors.

What is an EditingDomain?

In GMF, each diagram editor works on its own instance of a so called TransactionalEditingDomain. TransactionalEditingDomain is a concept from EMF Transaction. In GMF, it contains an EMF ResourceSet holding the diagram model, its semantic model and all referenced models as well as a command stack for undo/redo support. In addition, each editor registers a WorkspaceSynchronizer to its resource files, making sure external changes are synchronized with the editor's content.

Why share the EditingDomain?

In the default setup, problems occur if two editors operate on the same resources: If both editors change the same resource, saving one will overwrite the changes of the other. This situation already happens when you're using the Related Diagrams feature in the gmfmap model: On double click, it will open a new diagram that is saved in the same resource but in a different editing domain. As the original editor is still open, conflicts can arise quickly.

Another reason for sharing the editing domain is to save memory and performance, especially if you're working on big models with a couple of editors.

In many cases you might want to see changes immediately in all editors without having to save first, e.g. when your editors show different parts or aspects of the same model. GMF has already built-in support for that as it uses EMF's notification mechanism to synchronize the notation (diagram) model with the semantic model.

Consequences of sharing an EditingDomain

Sharing the editing domain across several editors has a number of consequences

• The editors will also share the same command stack. Undo/redo becomes a global operation and can therefore affect other editors than the currently active one.
• For reasons of simplicity, all editors should be saved synchronously, and they will all be either dirty or clean at the same time.
• You should no longer dispose the editing domain when closing an editor. That means, to avoid memory leaks you need strategy for unloading unneeded resources.
  
• The command stack will keep references to unloaded model elements, too, so you might want to have an garbage collecting strategy here as well or at least keep the command history short.

Solution in GMFTools

The solution in GMFTools is based on a WiKi page of GMF and a couple of newsgroup entries combined with our own experiences. It has been recently refactored to reenable the WorkspaceSynchronizer.

It comes in a number of aspectual template changes for the GMF code generator, an additional runtime plug-in and tool support for fixing the type registry, such that it is rather easy to consume even if you're not too familiar with the GMF runtime. Note that so far we have only been using it to generate plain diagram plug-ins, i.e. not for GMF's RCP generator.

The major changes are

• Redirect all creation statements of an editing domain to a new utility class and the dispose statements to an unloading tool.
  
• Make sure to use consistent element types.
• The common behavior of all XXDocumentProvider.ResourceSetInfo has been extracted to avoid synchronization feedback loops.

If you're interested in the details have a look at the WiKi-page.

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.

Source code for the screencast of Xtext and GMF

Having received a lot of positive feedback for my last post, I finally found the time to make the source code available. You can find it in the SVN repository of the GMFTools project.

I have put the installation instructions here.

Note that this is proof-of-concept code rather than production quality. See my previous post for implementational details. Also note that two open bugs

• http://bugs.eclipse.org/bugs/show_bug.cgi?id=281014
  
• http://bugs.eclipse.org/bugs/show_bug.cgi?id=284850
  

currently limit the fun a little bit, but we're at least working on the Xtext part.

Synchronized editors with TMF/Xtext and GMF

Well, here it is, the screencast showing a textual TMF/Xtext and a graphical GMF editor synchronized on the same model.

The example has been implemented with only a few changes to generated code: In Xtext, the following modifications were applied:

• A Formatter to define where to use what kind of whitespace, when the textual representation is derived from the semantic model.
  
• An IFragmentProvider that generates name-based fragments (IDs) for elements in an Xtext resource. That way, the correspondence of graphical nodes to semantic elements is preserved even if you delete a preceeding entity.
  
• An AbstractEntitiesJavaValidator has been implemented for Java based validation
  

On the GMF side:

• In the mapping model, I had to use feature initializers to make sure names are initialized properly on creation, to always have serializable models.
  
• In the generator model, I had to manually set the domain genmodel and the file extension.
  
• In the generator model, I enabled validation decorators and printing, and added the plug-in de.itemis.gmf.runtime.extensions from the GMFTools project containing a more sophisticated layout.
  

Additionally, I added a bit of glue code:

• An action to navigate from an EditPart to the textual representation, using Xtext's NodeAdapter.
  
• A listener that warns the user if (s)he's about to change a file that has already been changed in another dirty editor, and allows to abandon the changes.
  

The editor are synchronizing on save, to avoid GMF's canonical edit policies pruning nodes/edges belonging to temporarily lost elements.

Xtext plays well with EMF. It registers

• A resource factory for a specific XtextResource implementation that encapsulates the parser (text->model) as well as the serializer (model->text).
  
• An EValidator with a declarative Java implementation
  

CodeGeneration 2009

I am back at Cambridge (UK) for this year's Code Generation conference.

The itemis-Kiel team already arrived yesterday, and after a nice walk through the town and some fish and chips, I finished a showcase with a GMF editor on an Xtext model. So be prepared for another converging editors screencast soon :-)

The conference started this morning. Up to now, I have heard two talks: First, Kathleen Dollard from AppVenture talked about Template Specialization. Kathleen referred to the .NET code generation languages and their specific problems, e.g. with respect to modularity and extensibility. To me it looked like we've got more comfortable solutions in the Eclipse/Java world. Then, Sven and Sebastian talked about Challenges in DSL Design. They elaborated that todays external DSLs usually stop at modeling behavior because of the lack of an embeddable expression language. Looks like that's going to be one of the goals in the next version of Xtext. Right now I am guarding the itemis booth for a while, just to join the case study by Karsten and Heiko on their MDSD projects at Deutsche Börse AG.

Despite all prejudice against British food, catering is excellent. Thanks to the perfect organisation by Mark Dalgarno and Andy Moorley, we're going on a traditional punting trip along the river Cam tonight. Should I have brought my wetsuit?

Started GMFTools project

I've worked with GMF for several years now, and I've built quite a bunch of graphical editors using it.

On my way, I've come along several issues, problems and annoyances of the GMF framework. Some of these may be a matter of personal taste, others are just reoccurring topics and tasks, which unfortunately have never been really focused within the GMF project. As these are sometimes hard to separate, I've decided to collect my ideas, extract reusable solutions and share them by making them open-source. This way, I hope to share knowledge with other GMF users, get feedback (maybe even by the committers), provide examples for beginners, and of course make my own life easier.

Have a look at it at http://code.google.com/p/gmftools/, and, if you like it, feel free to use it. But please don't expect me to provide extensive support. Main topics covered are

• Sharing an editing domain among several editors
  
• Make GMF's development process easier, e.g. by bypassing unreliable reconcilers and provide a very simple UI to the code generator.
• Additional layouts, e.g. make labels fit into ellipses.
• How to implement non- or semi-canonical diagrams.

Of course your comments are very welcome.

Maybe there are even more people around willing to share GMF solutions...