Here is a list of changes made from v02 to v03.

1. Added support for graph editing inside the broswer window.
  + Editor no longer subclasses from Frame, instead it communicates
    with a ForwardingPanel or ForwardingFrame object. I could have
    made Editor a subclass of Canvas, but that would interfere with
    load and save. When ObjectSerialization works with AWT components
    I may change this again...
  + Palettes no longer subclasses from Frame.
  + Added EditorFrame to make it a little easier if your code still
    assumes that the editor is in its own frame.
For an example, see uci/graphedit/demo/InBrowserApplet.html and
SpawnedApplet.html.

2. Added ActionLoad and ActionSave. To load and save graphs using
Sun's ObjectSerialization library. The advantage is that you can load
and save instances of your own classes without adding any source code.
The disadvantages are that you need to get the Sun ObjectSerialization
library, the files it produces are rather large, it does not work in
browsers (for now), and when you run as an application you need to
allocate extra stack space if you intend to actually do a load or
save. The way to allocate more stack space under JDK is with a '-ss1m'
command line argument to the 'java' command. I would also like to
support saving graphs/diagrams/documents to databases and text files,
but I am hoping for feedback/contributions from users who know what
they want in those features.

3. Changed PaletteShape to PaletteFig to make class naming more
consistent.

4. Changed ActionComponent, ActionButton, ActionChoice to
ActiveComponent, ActiveButton, ActiveChoice. Removed ActiveMenu since
it was not easy to use for anything.

5. Changed the way that Palettes are assembled and handle events to
allow PaletteDecorators. Defined PaletteSticky to add a sticky
checkbox to any palette. Now most Palettes do not do any event
handling. Instead each Palette should be constructed with an instance
of PaletteTop which will do default event handling. Other
PaletteDecorators can be composed in as needed. See FlexibleApplet's use of
PaletteSticky. I don't think I'll put much more work into palettes as
they exist now. People can probably do better with a GUI builder. 

6. Moved example code into a new directory/package named
uci.graphedit.demo. The class formerly known as uci.graphedit.Example
is now uci.graphedit.demo.FlexibleApplet. FlexibleApplet now accepts
applet parameters to control the way that its windows look: it can be
embedded in the browser or open its own frames.

7. I added a new package uci.graphedit.contrib. There is nothing in
it for now. But in future versions code contributed by users will be
placed there. Hopefully your enhancements will be listed here in the
next release.

8. Improved efficency and reliability of redrawing in Editor. Now
repairDamage() is never forced, it can happen at most 20 times a
second, usually 10 times a second. Even if you call
RedrawManager#repairDamage() more often, it will only redraw when
scheduled. This means that if you drag a complex object, or a lot
of selected objects, around the screen, they will keep up with you
because intermediate positions will not be redrawn. It is possible to
queue up a lot of AWT events if you just keep dragging and dragging as
fast as you can. But there should be no problem in normal usage.

9. Added mutual exclusion constructs so that the views cannot be
redrawn while events are being processed. This eliminates a lot of the
dirt that appeared in previous version if you dragged objects around
too fast.  If you author your own actions or modes, make sure that
they call startTrans() and endTrans() on any DiagramElement's that are
modified.

10. Moved some redundant code from Editor, Mode, DiagramElement, and
NetPrimitive to a new class uci.util.EventHandler. EventHandler
basically defines a set of AWT-style event handling methods that
return false by default (e.g., mouseDown, keyDown). It also defines a
handleEvent method that calls a pre-processing hook, a transform hook,
dispatches the event to one of the specific event handlers, and then
calls a post-processing hook. For example, class Editor overrides the
pre- and post- processing hooks to lock and unlock its redraw
manager. 

11. Added keybinding support to class Mode. Now any Mode can easily
map keystokes to actions.  For example see ModeExampleKeys.

12. Added a class ModeStack to allow multiple Modes to be active in
one Editor at a time. The problem with a simple state-machine concept
of editor modes is that it is very difficult to provide pervasive
functionality (e.g. keystroke accelerators) across modes. Also it is
basically impossible to have nested modes (i.e., I temporarily go into
some special mode, and then I return to whatever mode I was in).
Editor now refers to a ModeStack instead of an individual Mode. Events
forwarded to ModeStack are forwarded to each of the Modes on its stack
until one of of them handles the event. When a mode is done (e.g., you
release the mouse button when creating a FigRect) then that mode is
popped off the ModeStack and that Editor automatically goes back to
ModeSelect (or whatever was next on the stack). 

14. Greatly simplified the event handling logic of Editor. Now Editor
forwards events to the current selection, the node under the mouse, or
the ModeStack.  There are no longer an specific event handlers in
Editor.  I very much want to simplify Editor because I feel it is too
complex for people to read and understand easily, and it is the most
central class in the system so I know everyone will want to read and
understand it.

13. Added FigRRect to draw rounded rectangles, FigPoly to draw
polygons, and FigInk to draw a shape kind of like an open polygon. I
also added the corresponding ModeCreateFig... classes. There are too
many ModeCreateFig... classes, I need to do something to reduce that.
FigPoly has some features not found in other Figs: it has the notion
of a current handle that is drawn a little differently, and it has an
event handler that removes the current handle when the user presses
delete.

14. Added ActionNudge to move DiagramElement's by a few pixels.

15. Defined new class ActionNull as a "No Op", or "do nothing"
action. This is potentially useful because sometime I return an action
or null, and that meant that all callers would have to check for a
null result. For example, see Mode#keybinding. Now the interface to
such methods is simpler because callers can always call doIt() on the
result, without having to check for null. This is currently not used.

16. Added ability to select objects by pressing Tab to cycle through
all the DiagramElement's in the current diagram, and Shift-tab to go
backwards.  If you have have nothing selected, the first item is
selected, if you have one thing selected the next/prev item is
selected, if you have more than one thing selected nothing happens.

17. Added stubs for scrolling, but scrolling will not really be
implemented until after I switch to AWT 1.1.

18. Added support for showing user level docs on Actions by selecting
one in the Execute Action dialog and clicking "About". This only works
if you are running under a browser.

19. Added user hint strings, a.k.a. mouse docs, that are shown in the
applet status line to tell the user what mode is the current mode and
what to do. This only works under a browser or appletviewer. In the
future I would like to ad an application status line or small status
frame. That is a good project for someone who wants to extend this
framework.


================================================================

I wanted to make these changes in this release, but I have delayed
them until the next release. This list shows my intent for the next
release, but things could change.

1. Change naming style to be more like Sun standard:
 + Change set and get methods to have "set" and "get" in their names.
 + Change many DiagramElement method names to match java.awt.Component
Basically I would like to make it easier to use GEF
along with other java libraries and frameworks. If DiagramElement can
be made to conform to java.awt.Component then that opens a lot of
doors. Also I would like to support Java 1.1, JavaBeans, and Miramba
Channels, but I don't know enough about these yet.

2. Loosen the dependcy on the Net-level classes that I
implemented. People working with different kinds of graphs way want
different implementations (e.g., a sparse connection matrix). I am
thinking of implementing a class for ConnectedGraph that would act as
a Facade (from the Design Patterns book) that would hide the
particular representation being used. I would introduce
AbstractFactory and Composite patterns here as well. 

3. Now the number of Mode subclasses is at least the number of Fig
subclasses because each FigX has a corresponding ModeCreateFigX.  I
would like to reduce the number of Modes and thus reduce the total
amount of code. In general I would like to keep GEF at less than
10,000 lines of actual code (not counting headers, blanks, and
comments) because I want students in 10 week courses to be able to
read it all and have time to do a project.

Of course there are hundreds of improvements that could be made to
make GEF a better drawing tool. I want to accomplish all of the
enhancements listed on the GEF Projects page, but I have to limit the
time I spend on this and let GEF users contribute. User contributions
are good because it saves overall effort for everyone, and it improves
the usefulness of the framework because the enhancements are known to
be needed by users.

