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"). For most features there are comments in the source code that indicate where the feature manifests itself. Also there are references in the feature list to bugs in the bug list. You can follow the references by using a multi-file search command (e.g., grep) or you can use tags if you use emacs. A tag file with entries for bugs and features can be downloaded from the GEF web site.
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 and in the code (if there is a marked place where something should be added).
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, and most of them are pervasive throughout the code, so there are not very many comments in the code that refer back to these features.
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:
![]() |
FEATURE: graph_representation Needs-More-Work 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. Currently I use one implementation of graphs, in the future I would like to define a set of interfaces and allow multiple representations (e.g., adjacency matrix). Also in the future I would like to support a node/arc representation of graphs, because ports are not useful for all applications.
|
![]() |
FEATURE: visual_updates When the state of the graph or DiagramElement 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: 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 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.
![]()
FEATURE: redraw_minimal | Only areas of the screen that need to be redrawn are actually redrawn. When one DiagramElement 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 DiagramElements very fast at lower quality, and then they can be redrawn when there is time to make them look nice. (for related work see http://www.cs.unm.edu/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 DiagramElement 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.
![]()
FEATURE: view_action_documentation | From the ExecuteActionWindow users can browse on-line help for actions listed in that window.
|
![]() |
FEATURE: editing_modes The GEF Editor can be in one of several input modes. Each mode interperts user input events and instanciates Actions for the Editor to execute. Modes can be combined on a ModeStack.
![]()
FEATURE: editing_actions Needs-More-Work | Modifications to the diagram and DiagramElements are not performed directly by the Editor or by editor Modes. Instead Action objects are instanciated to represent what is to be done. Then the Editor executes those Actions and stores them for later undo/redo. Currently the intent is for all modifications to go through Actions, but there are several modifications that do not use actions.
![]()
FEATURE: removing_objects | DiagramElements can be removed from a diagram by pressing delete, or backaspace, or by using a menu item.
![]()
FEATURE: selections | DiagramElements 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 DiagramElements exist at the point of a mouse click, the highest one in the back-to-front ordering is picked.
![]()
FEATURE: palettes | A GEF palette is an array of buttons that each perform an Action. This feature will probably be dropped in a future version.
![]()
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 | DiagramElements 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 DiagramElements 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 DiagramElements that overlap it.
![]()
FEATURE: event_skipping | Not all user input events are equally important. For example, one mouse move is not very important if it is followed immeadiately by another mouse move. The GEF Editor speeds up event processing by skipping unimportant events.
![]()
FEATURE: editable_properties | The properties of a DiagramElement 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 DiagramElement. In the future I would like to handle multiple selections
![]()
FEATURE: locked_objects | DiagramElements 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 DiagramElement 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. |
![]() |
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. |
![]() |
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, DiagramElement, Layer, Mode, Action, 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 liket 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 severak 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.graphedit.
![]()
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 attribute of DiagramElements.
![]()
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.
![]()
FEATURE: cross_development_environments | GEF compiles and runs under JDK 1.0.2 and JDK 1.1 on Solaris and Windows95. I compiled it under a few different compilers on the PC. Different Java VM's behaive a little differently, and I have put in some logic to try to work around variations in some cases (e.g., flicker free redraws don't work under JDK 1.0.2 on a PC, so that option is turned off by default when you run on that platform). Also, some Java 1.1 constructs will not even compile under JDK 1.0.2, so I have made limited use of the unix m4 utility to do conditional compilation. I am distributing two versions of the source, one preprocessed for JDK1.0.2, and one preprocessed for JDK1.1. Each version can generate the other if you have access to the m4 utility. |