Release Notes


Application conforms fairly closely to project specifications. Deviations are noted under 'Known Bugs.' Presents a drawing application permitting the user to draw pictures employing a few simple geometric shapes, then manipulate the contents of that picture.


Execution begins from the draw class, a simple driver which starts an instance of the drawingWindow class. This latter is responsible for most high-level operations, such as invokation of open/save, program termination, etc. drawingWindow creates the buttonPanel and canvasPanel classes, which orchestrate the tool and canvas UI, respectively.

An assortment of shapes is available to draw with, all deriving from a base Shape class (not to be confused with java.awt.Shape and its family). For each concrete shape there exists a corresponding descendant of the shapeTool class (rectangleTool for the rectangleShape class, e.g.) Each shape tool is responsible for serving as an intermediary between the Swing UI event layer and the native shape methods -- creating, moving, etc. As each shape is created, it is added to an instance of ShapeList, created by the canvasPanel instance for each window.

Tools not directly associated with shapes, namely the selectionTool and eraserTool are also kept alongside the shapeTool-derived tools in the toolPalette class, one instance per window of which is kept by the buttonPanel.

The toolPalette class retains one instance each of every tool, providing a Map-like interface to retrieve them. In some respects this serves the same purpose as a registry, while also managing the switching of tools and provision to those tools of font and color choices delivered from the UI. The procedure for adding a new tool to the application, aside from the particular act of writing the code for it, consists of adding a line to the constructor for toolPalette. During its construction phase, the buttonPanel class requests from toolPalette a list of tools, from which a series of toolButton objects (composite types adding simple properties to JButton).

Most "command" operations are performed through menus. Menus are built though the menuBuilder class; each class requiring the use of menus (drawingWindow and canvasPanel primarily) creates upon request a set of menuRequest and helpMenuRequest objects, assembled by menuBuilder into a MenuBar object. Each menu item has as its ActionListener an object derived from Command, whose Execute() method carries out the action specific to its type.

Load/Save are implemented though recording and restoration of state through methods in each object requiring as much. Each Shape-derived class, as well as toolPalette, buttonPanel, etc., possess a saveState() and loadState() method, which create and accept, respectively, an XMLElement object. XMLElement is provided by the NanoXML package (, a lightweight (26k) implementation of an XML parser. The parser deals directly with the saved files, building an XML document tree.


Written, tested &c on a Linux machine using Sun's JDK 1.3. Due attention was paid to avoiding platform-specific problems (e.g. path separators), but some things may have been overlooked.

NanoXML is required for load/save. A copy is included in the source tarball, and may be found at the URl above.

Security: unaudited, unproven. The JVM alone is >100MB of closed-source code, so like Scott McNealy said of it, "You have no security. Get used to it."

Icons used in buttons are stored as PNGs. The Windoze/Codewarrior JVM does not appear capable of reading these. A screenshot reflecting the correct appearance may be found at Due to patent encumberment of the GIF file format, provision of GIF icons was not a feasible option given the license applied to the application and general principles.

The default file extension is ".draw" -- this may cause trouble on operating systems with crippled filenames. At need, any other filename may be used as well.

Known Bugs

Devin Carraway, CS360 <>

Last modified: Sun Dec 10 23:03:22 PST 2000