InVaider is described in Jim Conti's MS thesis, which should be included
here somewhere.  There is both Postscript and LaTeX.  The figures are
in a separate directory in Postscript.  They are not included in the
Postscript for the thesis because we made them on the Mac, and Apple
Postscript is not portable enough to be included in LaTeX.  So, you will
have to print out the figures separately and paste them in the thesis,
like Jim did.

InVaider is a framework for visual programming languages built upon
HotDraw.  In depends very heavily on a structured metafigure hierarchy,
and makes very few subclasses of Figure.  It breaks a metafigure into
three parts, the metafigure proper, the visual manager, and the calculation
manager.  The calculation manager is the interpreter for the visual language.
The visual manager seems to be almost a replacement for Figure.  I'm not
sure exactly what is in visual manager and what is in the metafigure.

The code is not as easy to follow as it should be.  You should probably not
try to understand it without reading the thesis.  In particular, many classes
have no class comment.

InVaider reuses a lot of the design of FOIBLE, an earlier framework for
visual languages that was NOT build on HotDraw.  Jim used the word
Foible all over the place, consider it a synonym for InVaider.

There are three applications.  FlowKit is a simple dataflow language.
PertChart is obvious, and it is interesting to compare it with the
PERTChart defined in regular HotDraw.  DLCS is a digital logic construction
set, i.e. a digital logic simulator.  As usual, it is easier to understand the
applications than the framework.  In fact, the applications are quite small
and easy to follow, which is why I am optimistic about InVaider.

The user interface of InVaider is not consistent with other HotDraw applications.
In particular, don't edit values inside boxes with the TextTool.  Instead, using the
selection tool, click on a value with the left-shift key held down.  You will be
prompted for the new value.  It is illuminating to read the code for the
FoibleSelectionTool.  In my opinion, it would be better to just edit the value
with the TextTool, but then the FoibleValue would have to be told when the
TextFigure that it uses is changed.  This should be easy with HotDraw constraints,
and I even started working on it a little, but didn't finish.

I think that Jim took metafigures a little too far.  Whenever a design
breaks one object into several objects, it is always a little unclear
where each responsibility of the original object should be reassigned.
Almost everything ends up going through metafigures.  The SelectionTool
was changed so that even moving a figure is done by moving its metafigure,
instead.  The comments imply that this was done so that ports could move
links, but that is not a good reason.  If a metafigure needs to know when its
figure moves or changes size then it should depend on the figure.  Some of
the changes to tools and handles in InVaider were done just because
moving is done to metafigures, not figures, and this seems to me to be
unnecessary.  On the other hand, it makes sense for a tool to ASK the
metafigure whether the figure can be moved.  Unmovable figures are not
part of regular HotDraw, and are purely an InVaider extension.

Also, it appears that many of the InVaider classes are identical to their
superclasses, and are only initialized differently.  In my opinion, there
are so many classes that it is hard to see the forest for the trees, and
it would be easier to learn InVaider if we made these new kinds of
objects by calling different initialization methods on fewer classes.

Minor complaint: VPLMetaFigure doesn't need all those instance variables.
The boolean variables are constant for each subclass.  I'll change this
eventually, unless someone else does it first.

-Ralph