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
This latter is responsible for most high-level operations, such as
invokation of open/save, program termination, etc.
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
its family). For each concrete shape there exists a corresponding descendant of
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
ShapeList, created by the
for each window.
Tools not directly associated with shapes, namely the
eraserTool are also kept alongside the
tools in the
toolPalette class, one instance per window of which
is kept by the
toolPalette class retains one instance each of every tool, providing
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
class requests from
toolPalette a list of tools, from which a series
toolButton objects (composite types adding simple properties to
Most "command" operations are performed through menus. Menus are built though the
menuBuilder class; each class requiring the use of menus
canvasPanel primarily) creates upon
request a set of
menuBuilder into a
MenuBar object. Each menu
item has as its
ActionListener an object derived from
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
buttonPanel, etc., possess a
loadState() method, which create and accept, respectively, an
XMLElement is provided by the NanoXML
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 http://www.devin.com/cruft/cs360/draw/draw-mainwindow.png. 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.
buttonPaneldoes not limit its vertical size; it does adjust horizontally for larger sizes, but after an oversize font distorts it vertically it appears not to return to proper horizontal bounding. This may be a problem in Swing somewhere. For most fonts it isn't a problem, but the issue may be encountered with truetype fonts with unusually tall glyphs.