Category	Featured projects
scm	Subversion, Subclipse, TortoiseSVN, RapidSVN
issuetrack	Scarab
requirements	xmlbasedsrs
design	ArgoUML
techcomm	SubEtha, eyebrowse, midgard, cowiki
construction	antelope, scons, frameworx, build-interceptor, propel, phing
testing	maxq, aut
deployment	current
process	ReadySET
libraries	GEF, Axion, Style, SSTree
Over 500 more tools...

Subversion and IDEs
Eclipse
JDeveloper
NetBeans
Visual Studio
Subversion Hosting

Tigris.org (Whole-Site) Admin Contacts
Announcements mail list
Status Blog at WordPress
@tigrisdotorg on Twitter
Problem reports on the whole site
Problems and suggestions about individual projects should go to users@thatproject.tigris.org

Features of GEF v0.6

This file prepared on 98/04/18.

This file lists features of GEF. This is useful in seeing what is there, and can be a good place to start before diving into the code. Also this feature list is useful for informal regression testing: if you add something new, check to make sure that all the old features still work.

Each feature is named with a unique string (e.g., "drag_object_constrained").

Some features are planned but not implmented. These are left as projects for students or other users of this framework. These features are marked with "Needs-More-Work" here.

Most of these features are user-visible, meaning that they are something that the user can see and use. Some of them are programmer features that only the programmer can see and use. Most of the programmer features are in section 7.

My intent was mainly to list features, and to describe them only a little bit. A detailed description of each feature would be useful for on-line help, but it would take a very long time to write and it would need to be updated as GEF changes. I have given brief comments only where the names of features are not enough to describe them.

Feature list overview:

1. Basic Features
2. Drawing Features
3. Connected Graph Features
4. Viewing Features
5. Editing Features
6. Other Features
7. Programmer Features

---

Basic Features

• FEATURE: editor_frame
  The drawing editor can be placed in a JGraphFrame or a JGraph panel in any Frame, Applet, or Dialog.

• FEATURE: editor_in_browser
  The drawing editor can be placed in the browser window, or any place an AWT component can be placed.

• FEATURE: cross_platform Needs-More-Work
  GEF will compile and run under a wide range of operating systems and development tools. The main development tool used for GEF's development has been Sun's JDK on a Sparc and PC.

---

2. Drawing Features

• FEATURE: figs
  A GEF diagram consists of Figs (short for Figures) that are contained and ordered within a Layer. Figs can be individually manipulated.

• FEATURE: basic_shapes
  GEF provides DiagramElements for a wide range of graphics primitives.
  FEATURE: basic_shapes_rect
  FEATURE: basic_shapes_circle
  FEATURE: basic_shapes_rounded_rect
  FEATURE: basic_shapes_line
  FEATURE: basic_shapes_text
  FEATURE: basic_shapes_polygon
  FEATURE: basic_shapes_ink
  FEATURE: basic_shapes_image
  FEATURE: basic_shapes_group Needs-More-Work
  FigGroup implements groups of basic shapes, including other groups. Currently groups do not define properties that are shared by their elements, in the future I would like to be able to, e.g., set the line width a group and have its contents change.

• FEATURE: graphical_properties
  Each Fig has certain graphical properties such as location, size, colors, fonts, line widths, etc. These properties affect the appearance of the object and can be edited with a property sheet (see below). New subclasses can add their own properties by defining get/set methods as used by JavaBeans(tm).

• FEATURE: graph_visualization
  A GEF diagram can be used to display a connected graph. Nodes and edges in the connected graph representation are associated with FigNodes and FigEdges in the diagram. LayerPerspective maintains a GraphModel that represents the connected graph, and it can filter it to display only those parts that are desired in a given context.
  • FEATURE: graph_visualization_nodes
    FigNodes in the diagram visualize NetNodes in the NetList, or other node objects in your own GraphModel. FigNodes are basically a list of basic shapes that together define the look of a node. A single NetNode may be visualized by multiple FigNode and multiple types of FigNodes. The construction of FigNodes is handled by a GraphNodeRenderer.

  • FEATURE: graph_visualization_edges
    FigEdge in the diagram visualize NetEdges in the NetList, or your own edge objects in your own GraphModel.

  • FEATURE: graph_visualization_ports
    Some of the shapes in a FigNode may be used to visualize NetPorts.

---

3. Connected Graph Features

• FEATURE: graph_representation
  GEF supports a representation of connected graphs that consists of nodes, ports, and arcs. Ports are the connection points on nodes where arcs can be connected. Nodes, ports, and arcs can be defined in subclasses that add their own attributes and behavior. GEF accesses this connected graph representation through the interface GraphModel. A default implementation of GraphModel is provided in DefaultGraphModel. You can also implement your own graph representations by defining your own class that implements GraphModel. This design is similar to that used for TreeModels and tableModels in Swing.
  • FEATURE: graph_representation_nets Needs-More-Work
    A NetList contains a collection of nodes and edges. Ports are implicitly in the NetList because they are referenced from the nodes. In the future I would like to provide more graph-level operations such as finding the transitive closure of a graph or querying the graph to find elements based on their properties.

  • FEATURE: graph_representation_nodes
    A NetNode represents a node in a graph. It contains a collection of ports.

  • FEATURE: graph_representation_ports
    A NetPort represents a port on a node. It maintains a list of the arcs that are connected to that port.

  • FEATURE: graph_representation_arcs
    A NetdEdge represents a relationship between two ports (possibly on the same node). I currently do no support multi-edges (e.g., three-way edges) and parallel edges (two edges that both have the same source and destination ports) are not well supported.

---

4. Viewing Features

• FEATURE: visual_updates
  When the state of the graph or Fig properties change, those changes will be reflected in the display(s). Redraws are not directly forced by changes, instead a RedrawManager accumulates damaged regions and then redraws them when convinent (e.g., when there are no input events pending) and when the time is right to achieve a specified frame-rate (number of screen updates per second).

• FEATURE: layers
  A diagram can consist of multiple layers with each layer containing part of the diagram. Layers can also be used to show non-editiable backgrounds (e.g., a grid) or user-interface feedback (e.g., a selection layer, although that is not the way selections are actually drawn now). (for related work see "Using the Multi-Layer Model for Bulding Interactive Graphical Applications", Fekete et. al. in Proc. of the User Interface Systems and Technologies Conference 1996, pg. 109 - 117.)
  • FEATURE: layers_menu Needs-More-Work
    There should be a menu or list somewhere that lists all the layers in the current diagram and allows the user to focus input on one layer. This is not done yet.

  • FEATURE: layers_hidden Needs-More-Work
    It should be possible to hide layers to help the user focus on certain aspects of the diagram. This is not done yet.

  • FEATURE: layers_dimmed Needs-More-Work
    It should be possible to dim or gray-out layers to help the user focus on certain aspects of the diagram. This is not done yet.

  • FEATURE: layers_locked Needs-More-Work
    It should be possible to lock layers to prevent the user from (acidentily modifing) certain aspects of the diagram. This is not done yet.

• FEATURE: multiple_views
  A given diagram can be viewed in multiple editors at the same time and changes made in one editor will be reflected in all editors. Each view is identical to the others, except for editor characteristics such as the current selection and (future) zoom level.

• FEATURE: multiple_perspectives
  A given connected graph can be visualized in more than one diagram. Unlike views, graph perspectives are not all alike, each graph perspective selects a subgraph of the underlying graph to show. And each perpective may use different Renderers so the same nodes may be drawn differently based on context.

• FEATURE: redraw_minimal
  Only areas of the screen that need to be redrawn are actually redrawn. When one Fig changes state, only the area it occupies is redrawn. Actually it can be faster to redraw a somewhat larger area, but GEF does not redraw the whole diagram very often.

• FEATURE: redraw_off_screen
  Screen updates may optionally be done using an offscreen Image to produce flicker-free screen updates. This is the default behavior on most platforms.

• FEATURE: adaptive_redraw Needs-More-Work
  Different java platforms have very different performace characteristics. GEF dynamically adjusts is redraw policy and frame-rate to match the capability of a given java VM and the complexity of a given diagram. Currently, only the on-screen vs. off-screen policy decision is made automatically, adjusting the frame-rate is done through the preferences window. In the future I would like to introduce degraded drawing modes that draw Figs very fast at lower quality, and then they can be redrawn when there is time to make them look nice. (for related work see Pad++).

• FEATURE: zooming_panning Needs-More-Work
  
• FEATURE: visual_grids
  LayerGrid and LayerPolar are two examples of background layers that help people make nice looking diagrams. LayerPageBreaks gives a visual indication of where the drawing space will be divided into pages when printed.

• FEATURE: viewable_properties
  The properties of a Fig can be viewed in a property sheet.

• FEATURE: show_document Needs-More-Work
  When GEF is run from an applet it can cause the browser to switch to another web page to show on-line help, etc. In the future I would also like to do this for java applications.

---

5. Editing Features

• FEATURE: editing_modes
  The GEF Editor can be in one of several input modes. Each mode interperts user input events and instanciates Cmds for the Editor to execute. Multiple modes can be active at any given moment. They are kept on a stack with the most recently started Mode having the first chanve to process each input event. Modes are managed by ModeManager.
  • FEATURE: editing_modes_select
    ModeSelect is the default mode to start in and to come back to when another mode finishes. It is near the bottom of the mode stack and is never popped off.

    a. FEATURE: select_by_click Needs-More-Work
    Clicking on a Fig selects it. Shift-click is buggy.

    b. FEATURE: select_by_area
    Starting on the drawing background and dragging out an area with the mouse will select all Figs in the rectangle.

    c. FEATURE: select_by_tab_key
    Pressing the tab key when zero or one Figs are selected will select the first or next Fig. Shift-tab selects the last/previous element. The ordering of Figs is their back-to-front ordering.

    d. FEATURE: select_all
    A menu comand allows users to select all Figs in the diagram.

    e. FEATURE: select_inversion
    A menu command allows users to select all Figs that are not currently selected.

    f. FEATURE: select_none
    Clicking in the background area deselects all Figs.

    g. FEATURE: select_by_predicate Needs-More-Work
    In the future I would like to define a dialog box that allows users to select all Figs that fit certain criteria: e.g., select all rectangles that have line width of zero.

  • FEATURE: editing_modes_modify
    When the user drags starting from a Fig, the Fig is continously modified until the user lets go.

    a. FEATURE: drag_object
    The user can move Figs around by dragging them.

    b. FEATURE: drag_object_constrained
    Holding down the control key keeps the Figs moving only vertically or only horizontally.

    c. FEATURE: drag_handle
    Dragging on a handle of a selected Fig will change the state of the Fig, e.g., resizing it.

    d. FEATURE: drag_handle_constrained Needs-More-Work
    In the future control-drag on a handle will resize Figs in a constrained way.

    e. FEATURE: minimum_modify_delta
    Users sometimes accidentily mode Figs a little bit when they try to select them. GEF defines a minimum movement delta, if the user moves less than this distance then the Fig will not be modified. Once the mouse has moved more than this distance, all subsequent mouse movement modifies the Fig.

• FEATURE: editing_commands Needs-More-Work
  Modifications to the diagram and Figs are not performed directly by the Editor or by editor Modes. Instead Cmd (short for Command) objects are instanciated to represent what is to be done. Then the Editor executes those Cmds and stores them for later undo/redo. Currently the intent is for all modifications to go through Cmds, but there are several modifications that do not use actions.
  • FEATURE: undo_and_redo Needs-More-Work
    In the future the Editor will store all Cmds instances in a stack so that they may be undone or redone.

  • FEATURE: macros Needs-More-Work
    In the future users will be able to record a sequence of Cmds that can later be replayed, perhaps parameterized.

• FEATURE: removing_objects
  Figs can be removed from a diagram by pressing delete or by using a menu item.
  • FEATURE: removing_objects_delete
    Deleting a Fig just removes it from the diagram, it does not affect the underlying connected graph or other Figs in other diagrams.

  • FEATURE: removing_objects_dispose
    Disposing a Fig removes it from its diagram and also disposes of any underlying connected graph objects which may, in turn, delete other FigNodes or FigEdges in other views.
• FEATURE: selections
  Figs can be selected to identify them as targets for menu commands and keystrokes that create and execute Actions.
• FEATURE: pick_objects
  The user can click on any object to select it. Some objects can be hard to click on if they are small or consist only of thin lines. Picking an object actually determies if the mouse click was "near" a given object. When multiple Figs exist at the point of a mouse click, the highest one in the back-to-front ordering is picked.

• FEATURE: palettes
  A GEF uses a subclass of Swing's JToolbar to implements Palettes of Cmds. FEATURE: snap_to_guide
  A Guide is an object that changes points so that they line up better to make a nice looking diagram. For example, GuideGrid snaps points to a grid.

• FEATURE: align_objects
  Figs can be aligned with each other or to the grid in various ways: tops, bottoms, lefts, rights, centers, horizontal centers, vertical centers, to grid.

• FEATURE: reorder_objects needs-more-work
  The back to front ordering of Figs cn be changed in various ways: send to back, bring to front, send backward, send forward. In the future I would like to add Actions to reorder an object backward or forward such that it always causes a visible change, this means that it must continue to move forward or backward until it exchanges places with one/all Figs that overlap it.

• FEATURE: editable_properties
  The properties of a Fig can be edited in a property sheet.

• FEATURE: property_sheet Needs-More-Work
  GEF provides a property sheet window to display and edit the properties of the currently selected Fig. The properties of a Fig are determined by using JavaBean introspection. In the future I would like to handle multiple selections.
  • FEATURE: property_sheet_editors
    Each row in the property sheet window displays one property in a way that is appropriate for that type of property. This is part of the JavaBeans spec..
    a. FEATURE: rectangle_editor Needs-More-Work
    b. FEATURE: color_picker
    
  • FEATURE: property_sheet_auto_apply
    When the auto-apply checkbox is set, each change to the property sheet fields immeadiatly effects the selected Fig. If auto-apply is not set, then changes accumulate and are all applied when the user clicks the Apply button.

  • FEATURE: property_sheet_revert
    When auto-apply is not set and there are pending changes, the Revert button cancels all pending changes.

• FEATURE: locked_objects
  Figs can be locked which means that they cannot be edited in the editor, although they can still be modified via the property sheet.

• FEATURE: replicate_objects Needs-More-Work
  In the future I would like to implement a replicate command that makes many copies of a Fig with each copy transfomed a little bit.

• FEATURE: nudge_objects
  Sometimes users want objects to almost (but not quite) line up with each other, or they want to position an object at a specific place regardless of the Guide. By using the arrow keys users can move objects just a little bit.

• FEATURE: default_initial_size
  When creating new basic shapes users sometimes make very small shapes by accidentilly clicking the mouse. Also, it is common for users to want to create several shapes of the same size. In GEF a single click when creating a Fig will give it the same size as the last Fig that was created.

---

6. Other Features

• FEATURE: load_and_save Needs-More-Work
  Diagrams can be saved and loaded using Sun's ObjectSerialization library, which is part of JDK1.1. In the future I would like to support other file formats.

• FEATURE: printing Needs-More-Work
  Diagrams can be printed under JDK1.1. In the furture I would like to support multi-page printing, currently I only print the page nearest the origin.

• FEATURE: printing_config
  There are several configuration options that can be set via the Preferences dialog box, e.g., should background layers like LayerGrid be printed?

• FEATURE: preferences
  GEF provides a preferences dialog box that allows users to specify various preferences.

---

7. Programmer Features

• FEATURE: few_basic_concepts
  GEF is implemented with only a few basic concepts that are implemented in clusters of classes. The basic concepts are: Editor, Fig, Layer, Mode, Cmd, and Selection.

• FEATURE: standard_naming_conventions
  I have tried to use naming conventions that are like that used in java books and the Sun java code. For example, access methods are named getXXX and setXXX.

• FEATURE: well_documented_code Needs-More-Work
  I have tried to write javadoc comments for every class and most variables and functions. This takes a lot of time and is always incomplete. In the future I would like to see more invative uses of comments such as javadoc comments that include images, animated GIFs, or even applets. Also I would like to define better links between the requirements (basically this feature list) and the code. Also I would like to document (and possibly publish) the design patterns that are used in this framework.

• FEATURE: ten_week_learn_and_use Needs-More-Work
  I would like GEF to be small enough and simple enough for college undergraduates to use in a 10 week course (including learning the java language and doing something useful with GEF). This has not been well tested or measureed, although I know of several university students who have used GEF for class projects. In the future I may decide to split GEF into "GEF Lite" and "GEF Pro".

• FEATURE: adaptive_performance Needs-More-Work
  Java platforms vary in speed. I would like GEF to be useable on the slowest platforms and make use of the additional power of faster platforms.

• FEATURE: extensible_framework
  I have tired to design GEF so that new features can be added by adding new code in subclasses, rather than having to modify the source code that I distribute. People who are extending GEF should try to put their code in their own package, and try to minimize modifications to classes in uci.gef.

• FEATURE: integration_with_exising_code
  GEF can be used to build a new application starting from scratch, or it can be used to add a graphical interface to an existing application. Using GEF is easiest if you add attributes to subclasses of GEF classes, but if you already have classes in your own class hierarchy, they you must use delegation instead of subclassing. There are places in GEF that are intended for delegation, e.g., the owner property of Figs. GraphModels also provide a lot of power in adding a graphical front end to an existing application.

• FEATURE: scalable_to_large_documents Needs-More-Work
  Ideally GEF will handle large diagrams well. Currently most of the algorithms for picking, drawing, etc. are linear in the size of the diagram. I know this can be improved by using a spacial data structure (e.g., a quad-tree), but I don't know when I'll get to it. Loading and saving can take a long time. I think customization is key to scalability, and end-user customization is very limited right now.

• FEATURE: easy_to_navigate_code
  I have tried to make the GEF source code easy to browse by following careful naming conventions, providing cross-references, and examples.

• FEATURE: robust_code Needs-More-Work
  Error handling in GEF is generally inadequit and needs to be improved. However there are specific areas where exceptions are caught, e.g., when an Action is executed in the editor. Framework support for robust code is key to allowing contributions from a wide range of people. Security is also important, GEF may evolve to take on more browser-like features and run Actions, Modes, etc under different security managers.

• FEATURE: integrated_debugging_support Needs-More-Work
  Ideally the framework would help people debug code that they are adding to the framework. There is some support for that in the form of exception handling that prints out diagnostics, code to draw visual indications of how and when redraws are being done, and debugging println's that are guarded by checks for command line args (via the -D option to java).

• FEATURE: consistent_style Needs-More-Work
  Consistent coding style makes the code easier to read, work with, and make global changes to. GEF's coding style has changed over the last few releases and is still not entirely consistent.

---