The Graphical Editing Framework (GEF) enables developers to create client-side rich graphical editors based on existing domain models. Eclipse's GEF has a steep learning curve, and at times it can be difficult to understand even for developers fully accustomed to it. There are a number of technical challenges associated with using GEF that developers should be aware of and know how to handle. We discuss difficulties that GEF developers face, and we enumerate ways to overcome them. Topics include using GEF correctly, implementing features not provided by the framework, and avoiding misuses of GEF that result in errors and bugs. In particular we present thoughts on MVC logic separation, the role of edit policies, customized layouts and graphical techniques, and potential threading concerns. The tips and insights provided by this talk are useful for both new and experienced GEF developers. See http://www.architexa.com/labs#gef for more information on our work.

1. Creating well designed graphical editors
... and bringing them to the Web

2. Vineet Sinha Elias Volanakis
 
Elizabeth Murnane
  Works for EclipseSource
 Work for Architexa  Committer on Riena and
RAP
 Built visual dev tools:
 Worked on GEF during his
▪ Microsoft
▪ Masters
IBM
▪ Nokia
▪ Accenture
Anthony Hunter

▪ Progress/IONA
 Works for IBM
 Focus on solving
 Lead committer on GEF
developers' problems
(and GMF Runtime)
 Not modeling
 Building on GEF for 5 yrs

3. Creating a well designed Graphical Editor

 User Experience
 Key Concepts
 Coding Challenges
Bringing GEF apps to the web

 Demo
 Approaches & Challenges

5. Diagrams are not as useful when too many

items need to be shown. Try:
 Hiding less relevant nodes.
 Grouping nodes using visual containment or
layout constraints.
 Thinking of ways to show nodes in a smaller
representation.
If users need to scroll consider overlaying or

showing reminders of out of sight pieces.

6. Don’t want to force users to be manually positioning

nodes.
 Automatic layout is good.
 But it is always good to let the user change things
Laying out a set of nodes…

 has the problem that it often depends on the particular use-case
and on personal preferences.
 if there is more than one good option, it might be too vague to
implement it correctly.
Should think about how the layout will work with

 On inserting a node
 On adding or removing a neighboring node

7. GEF allows developers to take an existing application

model and create a visual representation of it.
It consists of three components: Draw2D, Zest, and GEF.

Draw2D provides support for layout and

rendering.
Zest provides support for JFace patterns

to create quick graphical views.
GEF provides for a MVC architecture,

supports users interacting with the model, and provides
workbench integration.

8. LightweightSystem provides link from Draw2d to SWT.

Figures are lightweight containers

forming a tree with preorder
traversal for painting, i.e. last is
shown on top with reverse for
hit-testing.
Layout Managers position children Figure and calculate

the preferred sizes.
Connections are also Figures positioned using

ConnectionAnchors having children like ArrowHeads and
Labels.

9. Viewer: foundation for displaying and editing

your model
 Adapter on an SWT Control
 Selection Provider
EditPart: elements inside a viewer.

Tool: interprets user input; represents mode.

Palette: displays available tools.

CommandStack: stores Commands for

undo/redo.
EditDomain: ties everything together.

GraphicalEditor: for building an Editor.


10. Source:
“GEF
Description”
Source: GEF Description

11. Stuff that we have learned over the last 5 years of GEF

development.
To put GEF in Context:

quot;Final Thoughts:

 ...
 Very rich framework
▪ Lots of predefined functionality
▪ Do very complex things with almost no code
 ...”
- Koen Aers, GEF Tutorial, EC08
If you want to do something look for an example that does it and

try to understand how.

12. What should be in the Model (and the Commands)

 No dependencies on the View and Controller
 Don't have references to EditParts, EditPolicies, and Figures here.
 Anything that needs to be saved.
 You might need two models
▪ One from before or one for an external purpose.
▪ i.e. A presentation model (as opposed to a business model).
The Deleting Command can be tricky with multiple levels of

containment and connections.
 quot;When objects (i.e. quot;nodesquot;) in a diagram are deleted, it is necessary to remove, in the
very least, the connections between the items being deleted, including contained
parts such as children, and any items remaining in the diagram. ... Care must be
taken in the implementation because both ends of the connection may be deleted
using multiple selection. To avoid deleting the connection twice, the application
should lazily determine which connections must be deleted. Do this inside the
execute() of the command. On undo, the connection will get restored just once. For
an example implementation, see DeleteCommand in the Logic example.quot;
- GEF Trouble Shooting Guide

13. Try to use EditPolicies

 By default the controller is where the most of the code goes.
 EditPolicies help in separation of concerns, and allow uniform
reuse of capabilities across different classes.
 Spend some time trying to understand what policies already
exist and what they do.
 Already provided policies have support for
selection, editing, connection management, etc.
You might have more than one type of child:

 Group children into compartments.
 Have your model have a set of fake children – one each per
compartment.

14. Layout

 Don’t try to create your own one, though highly constrained
layouts are ok.
 Be careful about custom stuff – it is very hard.
 Buy or port one from another layout package.
 Implement one from an academic paper if you need to.
Advanced Graphics:

 Antialiasing, Gradients and Shadows:
▪ These are possible, but each has its own complications.
▪ Look at the newsgroups for howto.
 Embossing, Blur, and Glow are more complicated – but
should be doable (see Filthy Rich Clients).

15. Animation

 Look at the flow example.
 Code is available, but you need to hook into it at the right places.
▪ You will need to capture initial and final node positions and incrementally set
the bounds of nodes as a set amount of time passes
Coordinates

 Shapes, Connections, and Anchors always deal with absolute
coordinates.
 Figures bounds are not absolute.
 These issues show up when doing using containment.
Threading

 GEF/Draw2D are not thread-safe
 Do not call methods on Figures from non UI threads.

16. GEF Description

 http://wiki.eclipse.org/GEF_Description
 http://wiki.eclipse.org/GEF_Description2
Red Book

 http://www.redbooks.ibm.com/redbooks/pdfs/sg246302.pdf
GEF Articles

 http://wiki.eclipse.org/GEF_Articles
GEF Trouble Shoting Guide

 http://wiki.eclipse.org/GEF_Troubleshooting_Guide
ANCiT Consulting - Eclipse in Clips - GEF CBT
