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.