Conquering Gef Part 1: Effectively creating a well designed graphical editor


Published on

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 for more information on our work.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Conquering Gef Part 1: Effectively creating a well designed graphical editor

  1. 1. Creating well designed graphical editors ... and bringing them to the Web
  2. 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. 3. Creating a well designed Graphical Editor   User Experience  Key Concepts  Coding Challenges Bringing GEF apps to the web   Demo  Approaches & Challenges
  4. 4. 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.
  5. 5. 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
  6. 6. 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.
  7. 7. 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.
  8. 8. 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. 
  9. 9. Source: “GEF Description” Source: GEF Description
  10. 10. 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.
  11. 11. 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
  12. 12. 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.
  13. 13. 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).
  14. 14. 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.
  15. 15. GEF Description    Red Book   GEF Articles   GEF Trouble Shoting Guide   ANCiT Consulting - Eclipse in Clips - GEF CBT 