These frameworks were created with a balance of design and evolution. Thanks to the C++ compiler and the care taken by all programmers involved in the source tree to date, the end result is far from heavy, but instead a seasoned toolkit with an edge in performance and representational power. With it a source-intensive programmer can create their own custom drawing editors that conform to standards, with no barriers for integration with other systems.
The investment required to be productive with this toolkit is sizeable, but then the investment in the toolkit by others that you get to leverage is sizeable as well. And the non-copylefted free software license of ivtools (and InterViews) protects your investment, leaving you free to engage in any commercial or non-commercial activity with the software, and to join up or go your own way with any community of programmers you can find in the future.
The first layer of C++ classes in ivtools (and InterViews) are fairly straightforward wrappers for the primitive constructs supported by the X protocol: elements of graphic state -- font, color, brush, pattern; and elements of graphical data -- point, line, multi-line, and raster. Originally part of InterViews 2.6, these classes were integrated into the main-line library of InterView 3.1 (the part that did not rely on an InterViews 2.6 backward compatibility mode), and remain largely unmodified in the ivtools source tree. A programmer of raw Xlib clients could reuse these classes without need for the rest of ivtools.
The next layer of C++ classes in ivtools, and chronologically the second layer to probably be developed in InterViews, is a set of classes for wrapping around X windows, the nestable rectangular portions of screen real-estate managed by the X server. The base class is Interactor. These classes are similar in architecture to the widgets of an Xt or Xt-derived toolkit like Motif. There are mechanisms for layout built into derived Interactors, structured-document primitives like boxes, glue, and trays, to allow for dynamic reallocation of screen real estate when windows are resized.
Interactors were the essential class of InterViews 2.6. But due to the inherent overhead in relying on the server to manage a complex pyramid of window ids, in InterViews 3.1 they were augmented by the flyweight glyphs discussed below. To support legacy code, and because they were used for the drawing area of idraw, the Interactors live on thanks to the InterViews 2.6 backward compatibility of InterViews 3.1. Little new development uses the Interactors outside of work done with the Unidraw application framework discussed below. A programmer who otherwise wanted to program in a Xt like way would probably use Motif or lesstif.
Structured graphics seem the first experimentation by the InterViews team in lighter weight objects for screen rendering, and the libgraphic in InterViews 2.6 was absorbed and re-used in InterViews 3.1 Unidraw. InterViews 2.6 programs that relied on libgraphic can be readily upgraded to Unidraw's copy of the classes. This framework has support for all the objects that idraw can render: line, multiline, polygon, ellipse, rectangle, open/closed spline, rasters, bitmaps. And support for groups of graphics (the Composite design pattern).
Unidraw was the thesis work of John Vlissides and lays a
foundation which he showed could be built upon with a schematic
editor, a GUI builder, and idraw. The layer which turned
Unidraw into idraw is another foundation laid on the first,
which was proof by induction of the utility of Unidraw. With
OverlayUnidraw, ComUnidraw,
FrameUnidraw, and GraphUnidraw in ivtools,
MapUnidraw, ProjUnidraw, UtmUnidraw, VpfUnidraw, DlgUnidraw,
and VhclUnidraw in vhclmaps we've continued building
our own repeated layers on the foundation. The idraw of
InterViews 2.6 and the fdraw in Fresco have proven to be similar
foundations where projects like
Target Jr and
IUE have used
similar layering of frameworks.
Glyphs are the more recent
structured document classes of ivtools (and InterViews). They are
structured document objects that can do some structured graphics
as well. The most complex example program for glyphs that came
with InterViews 3.1 is a structured document editor, doc. A
derivative of doc called lexi was the source examined in the
first Design Patterns book.
Programming and debugging with them is quite a different thing
from programming and debugging with libgraphic or Unidraw. The
rendering is procedural and TeX like, and requires a tracing of
the layout process to debug.
Fresco glyphs are
multi-platform glyphs evolved from InterViews glyphs
It can be built and used mostly without InterViews. Only a few
files are duplicated verbatim in the IV-common and
Unidraw-common libraries to facilitate this, the generic base
classes of Resource, Regexp, UList, and Iterator. It is a
fairly lightweight interpreter augmented with server capability by
ACE
objects. In addition to the stand-alone demonstrator comterp, this capability has been
integrated into drawing editors evolved from idraw. It makes
for an interactive drawing capability controllable by local or
remote commands, extendable by C or C++ programmers.
Unidraw: A Framework for Building Domain-Specific Graphical Editors
(unidraw.ps or
ftp://interviews.stanford.edu/pub/papers/unidraw.ps.Z),
John M. Vlissides and Mark A. Linton, Stanford University.
Glyphs: Flyweight Objects for User Interfaces
(glyphs.ps or
ftp://interviews.stanford.edu/pub/papers/glyphs.ps.Z),
Paul R. Calder and Mark A. Linton, Stanford University.
Reusing Unidraw and idraw, Scott E. Johnston and Jorge
A. Gautier, Vectaport Inc.
Application Foundations for Structured Graphics
Lightweight Glyphs
Extendable Command Interpreter
The interpreter embedded into ivtools was originally developed
for interpreting image processing algorithms. It evolved into a
stack-based interpreter for generic command processing; a C
expression evaluator written in C++ where new commands can be
added by C or C++ programmers.References
Applying Object-Oriented Design to Structured Graphics
(libgraphic.ps or
ftp://interviews.stanford.edu/pub/papers/libgraphic.ps.Z),
John M. Vlissides and Mark A. Linton, Stanford University