Freitag, 22. November 2013

5 Usability Flaws in GMF (and how to fix them)

Although GMF (Graphical Modeling Framework) editors are an endangered species and future editors will be developed with JavaFX there is still a bunch of GMF editors out there. And most of them have something in common: a lack of usability. The good news are that some usability flaws are easy to fix. In Yakindu Statechart Tools we spend a lot of time in improving the usability of our GMF Runtime based editor. Here is a random selection of 5 usability flaws in GMF and how we fixed them.

The following code snippets are just examples how a solution could look like. Most of the  snippets are still experimental and developed for specific use cases and should not be used as is!

1. Remove dithering connection anchors

Everyone who ever worked with a GMF based editor knows this annoying default behavior. You spend a significant amount of time arranging the diagrams connections to produce a nice-looking diagram. When everything looks pretty nice, you enlarge a node  - and all the connection routing work was only a waste of time....

 To fix this, you can use an that can be chained to a SetBoundsCommand and recalculates the IdentityAnchor position based on the resize delta. Create a customized LayoutEditPolicy and install it on the container EditPart as shown below:

installEditPolicy(EditPolicy.LAYOUT_ROLE, new XYLayoutEditPolicy() {
  protected Command getResizeChildrenCommand(ChangeBoundsRequest request) {
    CompoundCommand result = new CompoundCommand();
    AdjustIdentityAnchorCommand command = new  
         .getEditingDomain(resolveSemanticElement()), request);
    result.add(new ICommandProxy(command));
    return result;

2. Remove scrollable compartments and autoresize container hierachy

Working with GMF compartments is no fun. The compartment scrollbars look pretty ugly and diagram elements are hidden in non visible areas. Sometimes, edges are clipped because a node is not fully visible and you do not even know that the edge exists. A better approach is to always show all elements in the compartment. If your diagram gets too large, you should consider using sub diagrams instead of scrollable compartments. When adding new nodes to a compartment, the user has to enlarge the whole container hierachy by hand.

The auto-resizes the container hierachy if more space is required. Every note that is in the way is moved to prevent overlapping nodes. It has to be installed for every EditPart in the compartment:

installEditPolicy(EnlargeContainerEditPolicy.ROLE, new

3. Add a preferred size selection handle

This EditPolicy adds a new handle to the selection handles. If this handle is pressed, the selected node updates its size to the preferred size. The preferred size is the minimum size of the node, where all node children are visible. When modeling with the UML Tool Magicdraw I found this preferred size handle to be very useful, so I added it to my GMF based editors as well.


To add the preferred size selection handle to a node, install the to the nodes EditPart for the PRIMARY_DRAG_ROLE. Check the Type Hierachy carefully!

installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new

4. Highlight clickable areas and open direct editing on double click

It is a good idea to indicate clickable areas with a highlighted border, so the user immediately gets  feedback where he can open an in-diagram editor. These editors should open on a simple double-click, no matter which node is currently selected in the diagram. With GMF defaults it is only possible to open the direct editor when a node is selected.

To highlight clickable areas within the Diagram there is a (really simple) that shows a border on mouse hover to indicate a clickable area. To open the direct editor on double click use the .This DragTracker generates DirectEditRequests on double clicks and replaces the existing DragTracker of the EditPart like this:

public DragTracker getDragTracker(final Request request) {
  if (request instanceof SelectionRequest
    && ((SelectionRequest) request).getLastButtonPressed() == 3)
    return null;
  IDoubleClickCallback callback = new IDoubleClickCallback() {
    public void handleDoubleClick(int btn) {
  return new DoubleClickDirectEditDragTracker(this, getTopGraphicEditPart(),   


5. Add rich text editing support to direct editing

If you use direct editing only to set names for nodes, the default GMF Direct Editing behavior is sufficient. If you have a more formal language, for example an expression language, you should consider using Xtext to generate an editor for your grammar and integrate it into your GMF editor to support syntax coloring, validation and cross referencing.

For the technical details have a look at Xtext integration into GMF !

Keine Kommentare:

Kommentar veröffentlichen