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.

Multi-touch Gestures For JavaFX Apps Running in SWT

I am currently preparing a demo for my talk at EclipseCon Europe 2013. Embedding my JavaFX based graphical editor into Eclipse went smoothly thanks to the FXCanvas that bridges SWT and JavaFX. But I realized that multi-touch gestures did no longer work.

I filed a bug for that, but I could not resist trying to find out what's wrong myself. You may not know that the sources of JavaFX are open now. So after cloning their mercurial repo and browsing a couple of classes I found out that SWT's GestureEvents are neither converted to JavaFX GestureEvents nor transferred to an embedded JavaFX canvas. The implementation was simply missing.

So with some help by Tom Schindl and Steve Northover (thanks a lot, guys!) I hacked a solution that works fine for me, as you can see in the screencast below. If you're interested you can download my the code from github.