Overview of GEF v0.6

Section 1. Vision

Basically, I want to have a nice, stable graph editing and MacDraw-style graphics editing framework. I need that as a starting point for a tool I am building for my Ph.D. research, and I think that others need a framework like that as well.

Some of the goals of the framework are to support these features:

• Full editing of unstructured graphics, so that it is possible to make nice looking diagrams.
• Ease of use, so that people who are browsing the web can figure out what to do with my demos without having to read a lot of documentation.
• Connected graph editing, because that is needed in my application.
• Multiple, coordinated views, so that complex connected graphs can be visualized in different ways.
• Easy integration with application specific code, so that people can put a graphical front end on their applications without rewriting everything around my framework.
• Simple enough for college students to learn and use in 10 weeks.

I think it would be really interesting to organanize a "virtual software development team" over the internet so that: (1) I don't have to do all the coding myself, (2) the final framework is tempered by actual application, (3) we all get experience in distributed development, (4) I get in contact with professional developers for future collaboration, user testing, and even job offers. As virtual team leader I promise to integrate changes, run the project web page, suggest projects, and avoid duplication of effort. I am especially interested in instructors at universities who want to use this software as material for project classes (see the history section of the GEF home page).

The framework should promote the creation of good demos for the www. That means that they should download quickly, look nice, have enough features to look professional, and let the user get to the point of the demo without fighting with a difficult interface.

More importantly, the framework should promote the creation of good applications. It should have a rich set of basic features. It should be easily customized to a given application. It should look nice and be easy to use (or at least be like other applications).

Section 2. Overall Architecture

There are two main levels in the Graph Editing Framework (GEF) representation: (1) the net level, and (2) the diagram level. The net level holds nodes which are logical objects that may have application specific data and behavior. The diagram level made up of Figs for structured and unstructured graphics that visually depict the net and various annotations.

I expect that people will use the framework by extending it by adding new classes. In Java the class is the most important unit of syntax, version control, code distribution, and dynamic loading. I have tried design the framework so that people never have to modify existing code. I don't know if that is not the case yet, but hopefully it will be.

The graph editor (in class Editor) is just a shell that dispatches control to various other objects that do the actual drawing and processing of input events. The supporting classes are in several clusters described below.

Section 3. Class Clusters

• Editor is the most central class of the system. There is one instance of of Editor for every diagram that is displayed on the screen. Editor acts as a shell: Editor does not handle input events, redraw the screen, determine what item the user clicked on, or modify the diagram data structure itself. Instead it passes events and messages to supporting objects from the other clusters.
• Cmds are classes that define a doIt() method that performs some action in the Editor. For example CmdReorder handles the menu items 'Send to back', 'Bring to front', etc. Ideally, an action should be used for any modification or command that the user might want to undo, include in a macro, or get help about.
• Modes are modes of operation for the Editor. They can potentially be long term modes, for example preview mode vs. ray tracing mode. But so far I have only done short term modes for selection, modification, and creation of new objects. For example, when you drag an object around the Editor is in ModeModify, but when you release the mouse button the Editor returns to ModeSelect.
• Guides are objects that help the user make clean looking diagrams by constraining mouse coordinates. For example, GuideGrid implements grid snap.
• Figs are drawable objects that can be shown and manipulated in the Editor. Figs (short for Figures) are basic drawing elements such as lines and rectangles. FigGroup is the class for groups of Figs. Perspectives are compound drawing elements that represent objects in the underlying net level representation.
• Layers serve both to group Figs into transparent overlays (as in many high end drawing packages) and to manage redraw order and find the objects under a given mouse point. That is to say, they may serve as both display lists, and pick lists. Some Layers compute their visualization rather than storing a list of Figs, for example LayerGrid.
• Selections are objects used by the Editor when the user selects a Fig. Selections are responsible for drawing handles and handling dragging on handles.

Section 4. Coding Style

I am including this section (1) so that anyone who modifies this code can work toward the same style that I am tring to achieve throughout the source code, (2) as a form of documentation so that you know what you are reading. Unfortuantly, the code does not consistantly follow all of these rules yet, but it is close.

Section 5. Contact Information