You are on page 1of 12

.

ET++ - An Object-Oriented Application Framework in C++


Andre’ Weinand
Erich Gamma
Rudolf Marty
Institute for Informatics
University of Zurich
Winterthurerstr. 190
CI-I-8057 Zurich, Switzerland
E-mail: (weinand,gamma,marty]@ifi.unizh.ch
(weinand,gamma.marty)@unizh.uucp

Abstract workstations running Sun’s enhanced version of 4.2BSD


ET++ is an object-oriented application framework UNIX and SunWindowP. ET++, as we call the object-
implemented in C++ for a UNIX? environment and a oriented application framework, essentially combines the
conventional window system. The architecture of ET++ functionality of MacAppm [Sch86,Ros86] with an
is based on MacApp and integrates a rich collection of object-oriented flavour of the Macintosh toolbox [App85]
user interface building blocks as well as basic data while enhancing and generalizing the class hierarchy.
strut tures to form a homogeneousand extensibIesystem. Besides its uniform object-oriented implementation, the
The paper describesthe graphic modeI and its underlying novel aspectsintroduced in ET++ are:
abstract window system interface, shows composite . Its declarative layout specification for composite
objects as a substrate for declarative layout specification objects as found in dialog boxes modeled after a
of complex dialogs, and presentsa model for editable text system to typesetmathematicalformulas.
allowing the integration of arbitrary interaction objects. . The possibility to build up a hierarchy of
independently scrollable views.
1. Introduction . Flexible classesto handle text as a base to integrate
Since 1984 our research group worked on a UNIX based arbitrary objects.
toolkit to support high-level dialogs on bitmap-oriented Fig. I shows a screen with applications developed with
workstations. Our toolkit, called ET [Mar86], has been ET++.
used in several projects. It proved to be useful but
appeared to us as too rigid, especially after we started to 2. ET++ -Technical Objectives
think in object-oriented terms.
The principle aim in developing ET++ was to design and
In early 1987 we initiated a follow-up project to implement an object-oriented application framework for a
design and implement a fully object-oriented application UNIX environment with roughly the functionality of both
framework for UNIX environments. The implementation MacApp and the user interface elementsof the Macintosh
language is C++, our development and target systemsSun tOObOX.

t UNIX is a registered trademark of AT&T. Another goal was to unify the hybrid. structure of
MacApp and the non object-oriented Macintosh toolbox
into a single object-oriented application framework. We
Permlwon to copy without fee all or part of this material is granted provided
thar the copies are not made or distributed for direct commercial advantage,
believe that a major drawback of MacApp is the fact that
rhc ACM copyright notice and the title of the publication and its date appear, MacApp is only a thin Iayer on top of the Macintosh
and not~c IS given that copying is by permission of the Association for toolbox. The implementation of complex applications, as
Computing Machinery. To copy otherwise. or to republish. requires a fee and/
or spcctlic pcrmmlon. a result, always requires some intimate knowledge of both
the internal structure of MacApp and the Macintosh
0 1988 ACM 0-89791-284-5/88/0009/0046 $1.50 toolbox interface. We hoped that a single homogeneous

46 OOPSLA‘88 Proceedings September25-30,19&I


Find What
ation SunWindowPort

n Match Whole Word

-PostscriptPort

Figure 1: Someapplications developedwith ET++

system would strongly improve the efficiency of building did not want to implement a new window system, and
complex applications, especially for non-expert program- third, we believed that it is possible to find a small set of
mers. This would allow students develop CASE (Com- window system functions that is available in most
puter Aided Software Engineering) applications in short window systems or that can be adapted in a small
term projects. interface layer between ET++ and an underlying system.
We planned to realize the building blocks of the
user interface exclusively with concepts known from 3. The ET++ - Architecture
MacApp and to unify all parts of the implementation of The basic building blocks of the ET++ architecture are a
ET++ with a small set of basic mechanisms.If extensions class hierarchy and a small device dependentlayer mainly
should become necessary they should never make the mapping an abstract window system interface to the
overall structure of ET++ more complex and less elegant underlying real window system (Pig.2).
‘Ihe integration of foundation classes like those
known from the Smalltalk programming environment
[Go1831was another goal. The term integration not only
means installing these classesin the class hierarchy but
also supporting them with mechanismsfor interaction and
rendering on the screen.
Portability was a major issue in the design of ET++. Layor

In contrast to the Macintosh, a UNIX environment lacks Window System


an established window system standard. In order to UNIX
overcome these problems when building portable
applications, some implementorsof user interface toolkits
and application frameworks build their own window Figure 2: ET++ - architecture
system which either occupies the entire screen or lives
inside a native window of the host environment. This was Foundation classes represent basic data structures
not acceptable to us for a number of reasons: first, we (array, list, set etc.). The user interface classes
wanted to use all tools available on our Suns, second, we implement graphical eIementsfound in almost every user

September 25-30.1988 OOPSLA ‘88 Proceedings 47


interface toolkit such as menus, dialogs, or scrollbars. only a small programming effort.
Application classes are high level classesthat factor out The input/output facility of objects together with
the common control structure of applications running in a the flexible stream classes of C++ allowed a general
highly graphic environment. The inteqace layer provides implementation of a DeepCopy method. These stream
a small set of functions for window management,input classessupport not only the transfer of data to disk files
handling, and drawing on various devices. but also to a buffer in memory as well. The DeepCopy
The basic application classes are derived from method simply invokes the P rint On method to write an
MacApp and therefore have a similar behavior and similar object to a buffer in memory, followed by ReadFrom
interfaces. These classes are Application, that createsthe duplicate object out of this buffer.
Document, View, ViewFrame, Window, and Another application of the object input/output
Command. They provide methods for the managementof facility is a kind of inspector for an object. The method
documents,windows, and user commands. For a detailed Inspect defined in class Object uses the PrintOn
description of their structure and functionalities we refer method to display the state of an object in an inspector
to [Sch86a,App86]. window. This window registers itself as one of the
object’s dependents,If the inspected object follows the
4. Design and Implementation Aspects change propagation protocols and announcesits changes,
We will focus on the most relevant issueshere, in order to the inspector window will be updated accordingly and
show the main differences from other systems and to thus will always show the actual stateof its object.
illustrate the benefits of an object-oriented approach.
4.2. The Graphics Model of ET++
4.1. Foundation Classes ET++ supports a simple 2-D graphics model which lacks
Foundation classes are generally useful data structures. complex operations like scaling and rotating (we plan to
These classes are not strictly coupled with the rest of integrate zooming into the next release). The model is
ET++ and can be used autonomously. ET++‘s foundation based ontheclassesView,VObject.ViewFrame and
classes include a simplified version of the Smalltalk- BlankWindow. Unlike MacApp, all user interface
collection classes [Go183]. Examples are Ob jList elements like menus, dialogs and scrollbars are
(doubly linked lists), SortedObjList (sorted lists), implemented on top of theseclasses.
OrderedCollection (dynamically growing indexed
arrays), Set (lookup tables based on hashing) and 4.2.1. Abstract Drawing Surfaces (View)
Dictionary (tables storing a set of associations The view represents an abstract and possibly arbitrarily
between keys and values). These data structures are used large drawing surfacewith its own coordinate system.It is
heavily in the implementation of ET++ itself. Other subclassed to add a data structure which reflects the
useful data types included in the foundation classes are position of graphical elements.Its most important method
Point and Rectangle which are frequently used in (Draw) is called by ET++ whenever the View or a part of
the graphics building blocks. it needs to be redrawn. This method is never called
Change Propagation: Tools for graphical software directly by an application. Instead, the application
design methodologies often require a mechanism to informs the view on which rectangular part of its drawing
maintain the connectivity between individual graphical surface has changed and thus needs to be updated. The
symbols. ET++ supports the coordination among different next time the application is idle, ET++ will call the Draw
objects by a change propagation mechanism realized at method for the union of all invalidated rectangles,thereby
the root of its class hierarchy (by the class Object). avoiding unnecessaryredrawing. In addition, the Draw
Change propagation is modeled after Smallcall-80’s method is also called to print the View on other devices
changed and update principle. (e.g. printers) without need for additional code in the
InputlOutput of Objects: The foundation classes application.
provides the framework to transfer arbitrarily complex As a benevolent side-effect of this indirect drawing
objects from disk to memory and vice versa. This scheme it is always possible to simultaneously show a
functionality is based on the methods PrintOn and View or different portions of that View at severalplaces
ReadFrom which may he overridden to store orreadan on the screen without any need for additional support by
object’s instance variables. Input/output of pointers or an application. When an area of the View is invalidated
references to other objects are handled properly by the ET++ will redraw all places on the screenwhere that area
framework. Although C++ does not provide automatic is visible. Feedback functions like rubberbanding are not
activationlpassivarion as found in Objective-C? [Cox86], based on the invalidation mechanism for optimization
when working with ET++ object input/output requires reasons. They rather use direct drawing with an

OOPSLA‘88 Proceedings SeptemberW3O,i%88


exclusive-or raster operation. ET++ provides support for
automatically replicating this drawing to all places where
a view is visible. simple VObjects

4.2.2. Visual Interaction Objects


Drawing into a View can be accomplishedby using the
graphic primitives provided by the ET++ window system
interface (section 4.3). But most graphical operations are
basically executed to visually represent some conceptual
entity which has its specific interaction behavior (e.g.
buttons, menus, etc.). In an object-oriented environment
theseentities are best representedas objects. We decided
to introduce the abstract class VObject (visual object)
with a standard protocol for size management,for input
handling, and for the object’s rendering on the screen. Figure 3: View-hierarchy
VOb ject is the most general graphical class in the implementation and the conceptual graphics mode1
ET++ and, in this respect, corresponds to the class without sacrificing the concept of subframes. Moreover,
Object in the overall class hierarchy. The VOb ject is the model allows the contents of the sub-ViewFrame as
the result of an evolutionary process in which we tried to well as the View showing thesesub-ViewFrames to be
factor out the common behavior of all visual interaction independently scrolled.
objects.
An example for an application of this mechanismis
An instancevariable of type Rectangle holds the a View showing several dialog items. With our model it
VOb ject’s origin and extent which both can be modified
is possible to install an arbitrary View as a scrollable
and retrieved by a number of methods. In addition, a dialog item (text, item lists) in a dialog view.
VObject defines an abstract protocol for maintaining a
basepoint which is essential for the alignment of 4.2.4. Windows
VObjects representing text. Furthermore, a VObject
is also a subclassof the EventHandler, the root of all Up to this point we have only discussed Views and
classeshandling input. To react to a certain input event a mechanisms to render portions of Views in other
corresponding method must be overridden. A default Views. But Views are abstract; in order to make a
implementation forwards the event to another View visible it must be connected with some real areaon
EventHandler. thescreen.Thisleads us totheclass BlankWindow,the
root of all window classes.
4.23. ViewFrame In ET++ a real window (as provided by the
The most important subclass of VObject is the underlying window system) is considered as a “hole” in
ViewFrame. An ET++ ViewFrame is kind of a the screen desktop and thus corresponds closely to a
rectangular “hole? in a View through which another ViewFrame which represents a “hole” in a View. In
View or a part of it can be seen and scrolled. In other other words a window is a suliclass of a ViewFrame
terms, a ViewFrame establishesa clipping boundary and (called BlankWindow)which implementsthe bindingto
has its own coordinate system to show that portion of a the window interface. Like the ViewFrame, a
View which reflects the current scrolling position. BlankWindow has neither a border nor a title bar; it is
completely blank. Its main purpose is to implement the
Unlike a Frame in MacApp a ViewFrame has no
update mechanism (section 4.2.1) of the drawing model.
controls, no border, and no direct support for subframes A BlankWindow maintains a list of rectangular areas
(ViewFrames inside ViewFrames). But the lack of which represent the area on the screen that needs to be
these elements is not a deficiency of a ViewFrame
updated. Rectangular areas are added to this list
becauseaViewFrame isitselfa Vobject andtherefore
whenever a part of the window becomes damaged or
can he installed in a View like any other visual object.
exposed by some external event, or whenever the
This simple model allows us to build arbitrary hierarchies
application invalidates an area of a View shown in that
of Views as shown in figure 3.
window.
In order to realize subframesin a ViewFrame an
intermediate View is necessaryto install ViewFrames In addition, the BlankWindow implements the
event loop. Unlike the Macintosh toolbox, ET++ has no
and other graphical objects (VObjects). Although this
might appear as complex it dramaticahy simplifies both notion of an active window. All events are forwarded

September25-30,1988 OOPSLA‘88 Proceedings 49


from the window system interface to the visible window abstract output primitives with a device dependent
enclosing the current mouse position. Consequently, an implementation or add device specific methods. The
ET++ application does not have a single event loop abstract class WindowPort, for example, extends the
(located e.g. in the Application object) but an event output interface of a Port with methods for input
loop for every window. The window, in turn, forwards the handling and window management. The underlying
input events to the interaction objects it contains (Views, window system must actually only provide mechanisms
ViewFrames,VObjects,etc.). for the management of overlapping rectangular areas on
Windows with borders and title bars are the screen. All drawing including window borders and
implemented as subclasses of BlankWindow by adding title bars is performed completely under control of ET++.
a View which contains the appropriate graphical elements Thesubclass SunWindowPort isan implementationof
and a ViewFrame representing the Contents of the WindowPort for Sun workstations; an XWindowPort
window. (for X-Windows [Sch86b]) will soon be added.

4.3. The ET++ Window System Interface Open, Close


Stroke{Line,Rect,Oval,RoundRect,Arc,
In order to be independent from a special environment Polygon}
(e.g. a certain window system), system dependencies were Fill(Rect,Oval,RoundRect,Arc,Polygonj
encapsulated by introducing an abstract system interface ShowBitmap
defining the minimal set of low-level functions necessary ShowPicture
to implement ET+. These functions can be subdivided ShowChar, ShowString
into the following categories: SetClip, ResetClip, SetOrigin
GiveHint
graphical functions, window management, and
input handling
Figure 5: Graphics primitives
font, cursor, and bitmap management
operating system services. Usage of these classes is straightforward: ET++
All categories are defined as abstract classes which are to maintains a variable port that holds a reference to the
be subclassed for a specific environment or output device. current output port. All drawing primitives used in an
These subclasses are considered as the system interface application are automatically applied to this current port.
layer of ET++. The device dependent impIementation of the
As an example we describe the structure of the class graphic primitives of Fig. 5 is stateless, i.e. all primitives
hierarchy of the first category and discuss their interface take their drawing attributes as parameters. Because this
(Fig. 4). interface is cumbersome to use we added a second
interface which maintains state for attributes such as fill
pattern, fill mode, pen pattern, pen position, etc. thereby
Port (an abstract outputport) providing an alternative set of graphic functions with less
C++Port (generates the equivalent C++ parameters. Other interfaces exist to further reduce the
statements) number of parameters for common usages. All these
PicturePort (generates the ET++ exchange alternative interfaces are based on the stateless primitives
format for images)
PrinterPort (abstract printing device) implemented in the device independent portion of the
abstract Port and, as a consequence, do not enlarge the
PicPoft (generates pit-troff code)
device interface.
t PostScriptPort (generates PostScript) Except GiveHint all methods from figure 5 have
I WindowPort (abstract window device) an evident functionality. GiveHint provides a
mechanism to let drivers optimize their internal behavior
SunWindowPort (an implementation for by giving them some hints about the high-level structure
SunWindow)
t XWindowPort (a (planned) implementation of a sequence of graphic primitives. A certain value out of
for X-Window) an open ended set of constants specifies the additional
information for a specific driver. Most calls to
GiveHint come in pairs, bracketing a sequence of
Figure4: Port-hierarchy
graphic primitives. Notice that all calls to GiveHint are
of advisory nature only and can be safely ignored by the
The root of this hierarchy is the abstract class Port
defining the graphical output primitives common to all driver. There is also no need for an application to provide
hints by calling GiveHint. Three examples illustrate
output devices (Fig. 5). Subclasses of a Port override the

‘I OOPSLA ‘88 Proceedings September 25-30.1988


theusage of GiveHint:
Double Bu#iering. Double buffering provides for flicker Object
free screen update. This simplifies the implementation
becauseit is no longer necessaryto minimize the update
region by sophisticated and complex strategies. All
drawing requestsbetween a pair of GiveHint calls are
done in a memory bitmap whose size is given as an
argument.At the end of the sequencethe bitmap is copied
to the screenin a single operation. CodeTextView
Character Batching. The text classes display text RestrictedTextView
essentially by calling the method ShowChar. It may
seem inefficient passing every single character through
the device switch and the clipping machinery of the
window system in order to get displayed. On the other
hand, the complexity of the text manipulation classes
would increase substantially if only the method
ShowString would be usedjust to optimize speed. TO CheapText
overcome this dilemma, the method GiveHint is used t GapText
to inform the driver when a new Iine starts and again
when it ends. With this information at hand the driver is
L StytedText
able to collect single charactersof a line into some data L VObjectText
structure (a batch) and use one single optimized operation
to clip and display the entire batch.
High Resolution Printing. In this context GiveHint is Figure 6: Text Classes
used for high resolution printing of text, e.g. on a
PostScript printer. Usually, all text positioning is based together with the bounding box and the baseline.
on screen pixel coordinates. But a PostScript printer is CheapText is the simplest implementation of a
able to adjust characters much more precisely. text data structure and is typically used by dialog items.
GiveHint may be used to give additional information The underlying data structure is a dynamic character
about synchronization points within a line to a PostScript array. GapText should be used for larger texts and
driver. implements the text abstraction as a characterarray with a
gap such as found, e.g., in the text package of the Andrew
4.4. Text Handling system [Han87]. A subclass of GapText. the class
Manipulating text is an essentialpart of most applications. StyledText , supports multifont text,
Text editing features are typically needed in many An interesting subclass of Text is VOb ject -
different contexts such as dialog boxes (dialog items), Text. The protocol supported by visual objects (section
diagrams(annotations),and browsers (program text). Our 4.2.2) makes it possible to consider a VOb j ect as a
goal was to design a framework that can be used in a glyph that can be integrated into text and behaving as an
general way. To achieve this goal we strictly separated ordinary character. This integration of VObjects into
between a class to render and format text (TextView) text is realized by the class VObjectText which
and classesfor managing the data structures to store the extends the methods for cutting and pasting text
text. These classes are descendantsof an abstract class intermixed with visual objects. Fig. 7 shows an instance
Text defining a standardized protocol for all Text of a VObjectText rendered by a TextView:
classes(Fig. 6). To display and edit a text, an instanceof a Applications of inserting instances of VOb jects into a
subclass of Text is passed to a TextView. The text are dialog items such as buttons or annotation items
TextView acts as Controller and View in the model- as found in hypertext systems.In order to make the dialog
view-controller (MVC) [SchMa] paradigm, the instance items in the text responsive to user input, the methods
of a Text class representsthe Model. The most important interpreting input events of the class TextView have to
(abstract) methods of the class Text are Cut, copy, be overridden to call the corresponding method of the
Paste, and GetIterator. The method Get- VOb ject. Remember that visual objects are a subclass
Iterator returns an instance of the class Text- of EventHandler and therefore support thesemethods.
Iterator. Thisiteratorretrieves a sub-sequenceoftext TextViewitself isasubclassof VObject anditisthus
character by character, word by word, or line by line possible to nest instances of the class TextView

September25-30,1988 OOPSLA‘88 Proceedings 51


dialog items to enter floating point or integer numbers.
Following our goal to use uniform mechanisms
Fonts Styles sizes Format
wherever possible, the implementation of the class
An example of a VObjectText TextView uses the same mechanism for invalidating a
;ome Examples of instances of UObJecis in a tent. This item region of a view in order to update the screenas described
s an onnofaled/fem. Clicking on it pops up a window to edit in a previous section. The possibility of double buffering
m annotation. Other examples ere
\ an tlctiongutton
/ or some considerably reduced the implementation effort for the
30@@ rat/u buffuns. The neHt two eHomples are text building block. We did not have to design an
UeuMusmer that con be ScrotIed independently of the rest 01
he tent: incremental update algorithm to reduce the amount of
flickering on the screen. With double buffering we
achieved a flicker free screen update, even for text
displayed against arbitrary backgrounds.

4.5. Dialog Classes


Dialog items like menus, buttons, scrollbars, and editable
texts are the most basic elements of an interactive user
interface and are available in almost any user interface
o linish 1 an instance of a Borderltem toolkit. But usually there is only a fixed set of them and
no simple way to build new dialog items from existing
ones or to construct them from predefined lower level
components. A button, for example, may consist of an
Figure 7: An example of a VObjectText image or text, a single or double borderline, and a special
behavior to react on mouse clicks. A scrollbar typically
recursively. ViewFrames areasubclass of VObject
consists of an up and a down button together with an
and their instancescan be integrated into a text, too. Since analog slider which itself may be a filled rectangle, an
all applications use ViewFrames to display their
image, or even a number reflecting its current value. All
Views and since the class VObjectText establishes theseparts may be useful for other kinds of dialogs or in a
the ground to integrate them into a text we have build a completely different context.
flexible yet simple framework to integrate text and
graphics. In Fig. 7 the MouseView from [Sch86a] is At tirst sight multiple inheritance seemed to be a
installed in a ViewFrame and integrated into the text. possible way to combine various kinds of basic classesto
Associated with the ViewFrames is their scrolling form the complex items mentioned above. But on second
mechanism. This means, that it is possible to scroll the thoughts it became obvious that multiple inheritance was
View shown in the ViewFrame (the mouse picture) not the mechanismwe were looking for. As an example,
independent from the rest of the text. The insertion of multiple inheritance does not allow combination of a
ViewFrames into text is an example of a view hierarchy TextItem and two BorderItems in order to get a
(section 4.2.3). Given the general abstraction of DoubleBorderedTextItem
VOb jet t s, the implementation of this special kind of Another observation was that dialog items most
text structure was very straightforward. often come in groups. The Macintosh printing dialog, for
A graphical editor, e.g., rises TextViews for example, consists of about 30 different items which are
annotations and installs them directly into its own view. placed nicely in a dialog window. On the Macintosh the
In order to get scrollable text in dialog boxes or in a placement of dialog items can be done interactively with
program editor a TextView has to be installed in a the resource editor. But if the size of a single item
ViewFrame. The predefincd class EditTextItem changes,the overall layout of the dialog has to be redone.
used in dialog boxes is simply a subclassof ViewFrame Moreover, the precise horizontal and vertical alignment of
showinga TextView. The class CodeTextView adds text items is a tedious task if done interactively. This lead
auto indenting and find-matching-bracket features to the us to integrate some layout management based on a
functions provided by a TextView. Instances of the hierarchical and high level layout description rather than
class RestrictedTextView are used whenever the on the explicit placementof items.
edited text has to conform to a client specified format. We found an almost perfect approach in the UNIX
This format is specified with a regular expression and text processing tool eqn [KerX], a trofl-preprocessor for
checked upon every insertion or deletion of text (there is a typesetting mathematics. Eqn translates a simple
class RegularExpression in the foundation CkiSSeS). description of a formula into a sequence of typesetting
A typical application of RestrictedTextViews are commands. The basic items of eqn are characters or

52 OOPSLA‘88 Proceedings September 2530,1988


strings which can be pieced together with a number of The most important subclassof a DialogNode is
layout operators to form more complex items: Repeated the Cluster which implements a tabular layout of the
grouping of items finally leads to a tree representationof contained VOb jects. The commonly used horizontal or
the formula. vertical lists of items are special casesof a general layout.
We used this approach to implement all our dialog Each item can be aligned in a Cluster horizontally as
classesin the following way: a dialog is considered as a well as vertically in a number of ways (left, right, center,
tree of VObjects, with simple VObjects top, bottom, base).
(Text Items, ImageItems etc.) as leafs and The Cluster presentsa very powerful mechanism
COmpOSite VObjects (DialogNodes) as inner nodes. to fit the needs of complex dialog layouts without having
A DialogNode is a object that allows several to position items explicitly (Fig. 9).
VObjects(e.g. a Collection) tobecombinedintoa
single, composite object which can be treated as a unit.
The class DialogNode is abstract because it does not
know anything about the layout of the VObjects it
contains. Its main purpose is to apply methods executed
on itself(such as Draw,Highlight.Move etc.)toau
of its components and to forward input events to one of
them. Subclassesof DialogNode are responsible for
controlling both the communications between their new BorderItem(new TextItem("Lines"),
components and the relationship between the location of new OneOfCluster(HLeft,
thesecomponents. new ClusterWBase,
Fig. 8 shows the dialog portion of the class hierarchy. new RadioButton,
new TextItem ("none"),O),
new Cluster (VCenter,
VObject new RadioButton,
new ImageItem(imagel),O),
Textltem (non-editable unformated text) new ClusterWCenter,
hageltem (him image) new RadioButton,
new ImageItem(imageZ),O),
Button new Cluster(VCenter,
new RadioButton,
ActionButton new ImageItem(image3),0),
t OnOff8utton (a button with state) 0
1,
RadioButton 1;
t
ToggleButton
Figure 9: A dialog and its defining statement
f DialogNode (a composite VObject)

AnalogSlider (A VObject with any The Oneofcluster used in Fig. 9 is a subclass of


number of thumbs) Cluster that implements the one-of behavior of several
L ScrollBar on-off-buttons.
Borderltem (a VObject with border and title) A DialogView implements a standard behavior
1 CluStW (a compositeVObject with a
for modal or modeless dialog boxes. Its method
tabular layout) DoCreateDialog must be overridden to create the
OneOfCluster dialog as a tree of dialog items. In DoSetupDialog all
t ManyOfCluster
initial settings of dialog items should be done. The
method Control must be overridden to react to all
dialog interactions.
Figure 8: Excerpt of the dialog classes In addition, the DialogView registers all
EditTextItems, maintains an active insertion point,
A Border It em, for example, draws a borderline around and allows cycling through theseitems with a key.
its contents and displays an optional title centered above
its contents. The contents as well as the title are
consideredas VOb j ec t s .

September
25-30,1988 OOPSLA‘88 Proceedings 53
4.6. CollectionView and Menus The last step was to replace the special layout
Another specialized view is the CollectionView, algorithm by a dialog item of type Cluster to further
which displays any collection of VOb ject s as provided reduce the sourcebulk of CollectionView.
by the foundation classesin a tabular format. In fact its
implementation is based on the class Cluster of the 5. The Anatomy of an ET++ - Application
dialog classes. It also takes care of selecting and This section tries to give an impression of how the
deselecting single items as well as contiguous and non- different classes of ET++ fit together and what they
contiguous areas of items. The CollectionView is a contribute to a typical application. We briefly discuss
basic building block for all user interface objects which some structural and functional properties of the tree editor
have to present a collection of selectable items. It is the displaying the class hierarchy in Fig. 1. This tree editor is
root class for menus, menu bars, tools’ palettes, or a very simple application of some 500 lines of code but
scrollable lists of dialog items. Due to the very general neverthelessshows the most important characteristicsof
natureof CollectionView a Menu, fOreXan@e,ciUI an ET++ application.
always scroll and show items not only as lists but also in a The following features are automatically provided
tabular style. Hierarchical popup menus are implemented by the application framework classesand need no special
with items of class popup 1tern,, which contain a programming effort.
submenu in an instance variable and implement the
- scrollable views (including autoscrolling)
special behavior to open thar submenu.
The evolution of the classes CollectionView splittable views allow several panes (e.g.
and Menu illustrates a very interesting example of the ViewFrames) hking on disconnected pOrtiOnS

principle “Promotion of Structure” as defined in [Ste86]. of the tree view


- multiple documents in multiple windows and
In a first version of the chss Menu, the item list
was implemented as a simple linked list for efficiency window managementdialogs
reasons. Later it becamenecessaryto have the items of a - automatic file and dialog managementfor loading
font menu sorted alphabetically. The first idea was to and storing a tree onto disk
integrate a sort method, but on second thoughts we printing of a view and dealing with multiple pages
decided to replace our linked list in the implementation of
generating the ET++ exchange format of images
the chss Menu with the more general data structure
Co 1 lect ion found in the foundation classes.To show a which can be read by other ET++ applications, for
sorted menu it was now only necessary to use a examplea graphics editor
SortedObjList ratherthanan ObjList. - double buffering for flicker-free screenupdate.
At that time the class Menu was basically a View The implementation of the tree editor reveals the high
which could render a Collection of special reusability of the ET++ classes and centers around the
MenuItems as a vertical list from which one item could Di a 1 ogNode which provides a convenient framework to
be selected with the mouse. This mechanism seemed handle the layout managementof several subtrees. The
useful in itself e.g. for implementing a palette of tools subdivision of the window into a dialog and a tree part is
like the one found in MacDraw. Consequently the next another application of the layout mechanismprovided by
step was to factor out this mechanism into a class called the dialog classes.
Collectionview. The visual representationof inner nodes and leafs
Simultaneously, we extended the layout algorithm of a tree are just instances of the very general class
to show a Collection not only vertically but also in a VObj ect . The current implementation usessimple static
two-dimensional style. With this extension the Text Items, but the modification of a single line would
CollectionView became one of the most reusable suffice to replace them with a full-fledged text editor (e.g.
parts of ET++. We became able to build not only menus an EditTextItem). Forwarding of input events is
but also menu bars for Macintosh-style pulldown menus, implemented in the DialogNode. Maintaining an
scrollable lists of arbitrary items, and tools’ palettes with active insertion point is handled by the DialogView.
a few lines of code. A DialogNode manages a Collection of
In yet another step we extended the arbitrary VOb jects. Thus, the resulting data structure
CollectionView toworkwiththegeneral VObject underlying the tree editor is basically a Collection of
instead of a more specialized MenuItem which enabled Collections. Transfering this data structure to disk
us to implement the graphics part of a simple spreadsheet and reading it back into memory is almost completely
application with each cell containing a full-fledged text handled by the foundation classes. As long as no new
editor with just a couple of lines. subclassesof VOb jects are inserted into the tree no

54 OOPSLA ‘88 Proceedings September 2!5-30,1988


additional code for input/output has to be written. Table 2
The implementation of undoable commands, e.g. %ofall
relinking of leafs and subtrees is substantially simplified level classes
with the class Command and the possibility to make classes
deepcopies of arbitrary objects. This provides an easy 0 13 9.1
way to make a copy of a subtree before executing a 1 24 17.1
command. 23.6
2 33
6. Current Status 3 19 13.6

The ET++ class library is currently in use by three groups 4 16 11.4


at our institute. Recently, we started to use ET++ in 5 18 12.9
student projects. During the development of the class 6 11 7.9
library several applications evolved which were used to 7 6- 4.3
test the functionality of ET++: A drawing program
comparable with MacDraw which also supports 7. Related Work
connections between graphical elements, a tree editor The architecture of MacApp provided the base for ET++.
used to browse in the class hierarchy (Fig. 1). and a There already was an effort in the Intermedia project
spreadsheet,just to name some. [Mey86,Yan88] to port the MacApp framework to non-
Macintosh environments such as Sun workstations or
6.1. Some Statistics IBM RT PCs. Their approach differs from ours in that
The current implementation consists of 140 classes they based their MacApp framework on a port of the
containing 1653 methods. 309 of these methods are C++ Macintosh toolbox, CadMac done by Cadmus Computer
inline functions typically used to access instance Systems.CadMac is implemented in conventional C and
variables.Only a subsetof these classesand methods has does not use object-oriented techniques. Intermedia
to be known for using ET++. extended the object structure of MacApp by introducing
Table 1 special subclasses for their hypermedia system. The
resulting system is not integrated into a standard window
I lines of code 1 classes I methods I system. Intermedia is currently one large integrated
process with the disadvantagethat it is impossible to run
Foundation 6ooo several tools simultaneously. Due to its smooth
34 403
Classes integration into an existing window system, tools
Application developed with ET++ can run in parallel with already
13200 97 1071 existing ones.
Framework
I Another user interface toolkit available for UNIX
Device environments is IC-PAKfw 201 [Cox86]. The IC-PAK
Interface 6800
(3~C) 1 9 1 179 1
201 class library from StepstoneTHis a collection of
Objective-C classes which they call user inre$zce
We estimatethat around 30-40 classesare used to develop software-Es. The main point where ET++ and IC-PAK
a typical application. Our class library comprises 23000 201 differ is the user interface architecture they are based
lines of C++ and 3000 lines of C code (Table 1). C has upon. IC-PAK 201 uses Smalltalk-8O’s model-view-
only been used in the interface code to the window controller (MVC) paradigm whereas ET++ is based on
system. Table 2 shows the distribution of the classes MacApp. Beyond this architectural difference ET++
among the different levels of the hierarchy giving an provides a richer set of user interface classes. Unlike
indication of the degreeof subclassingused in ET++. MacApp or ET++, IC-PAK does not support automatic
transparentprinting.
(Level 0 contains the class Object and other classesnot
derived from Object). These numbers give an idea of Other object-oriented class libraries for Unix
the high-reusability of the classesfor the implementation environments typically addressonly a subsetof the needs
of ET++ itself. of graphical applications. For example the object-oriented
program support (OOPS) class library [Gor87]
correspondsroughly to the foundation classesprovided in
ET++ but provides no classes except Point and
Rectangle for building graphical applications. We
were not able to base our work on OOPS because it was

Seplember25-30,1988 OOPSLA‘88 Procedings 56


not available when we started. OOPS offers some tation of a DeepCopy method. Another application of
interesting classesnot provided by our foundation classes streams is a text window with a stream interface that is
especially the ones to program with coroutines similar to used to display debug messages. Its implementation
those of Smalltalk-80, consistedof overriding one method of a streamclass.
The X Toolkit lRao87] coded in conventional C The strict compile time checking of C++ was a big
with some object-oriented conventions is based on the help for the parallel developmentof ET++. When merging
abstractionof a widget. This is an object providing a user our development efforts, the new version was in most
interface abstraction roughly corresponding our casesup and running as soon as it compiled error-free.
VOb jet t s. The X Toolkit includes a set of implemen- ET++ has been developed with a C++ version not
tations of this abstraction, for example, buttons, labels, supporting multiple inheritance. The current class
forms, or scrollbars. The functionality provided by these hierarchy of ET++ is easy to understand and we are not
classes is comparable with the user-interface classes of sure if we would have arrived at the same clear class
ET++. The main difference between ET++ and the X structure had we begun with multiple inheritance in the
Toolkit or other frameworks for X windows such as first place. We are looking forward to experimenting with
Interviews Kin871 or the Andrew Toolkit Ipa1881is the the new version of the C++ compiler supporting multiple
homogeneous integration of foundation and application inheritance.
classes providing, for example, the base for undoable
commands or mouse tracking. Another difference is that In contrast to Objective-C, C++ does not provide
these systems are not based on a graphical model any information about the class structure or the field
separating between Views and ViewFrames allowing layout of an object at run time. Having some of this
the transparent integration of features like scrolling, information available, input/output of objects could he
autoscrolling, or splittable views into a framework. The X provided at the root of the class hierarchy for all classes.
Toolkit and Interviews are tightly coupled with the C++ has no built-in facility to check the type of an object
underlying X window system. An exception is the at runtime, With some programming conventions it is
Andrew Toolkit which is based on a similar abstract possible to implement an IsKindOf method in the class
window system interface as ET++. Another feature of the Object . This is done in the OOPS library, and in ET++
Andrew Toolkit is the integration of dynamic linking into we use a similar scheme. But this leads to different roots
an object-oriented environment. Recently we started of the classhierarchiesand to different conventions.
experimenting with dynamic linking in ET++, too and we Executable modules produced with the ET++
integrated this feature transparently with our object library are quite large (0.8-l MByte). For our draw
inpu;/output facility. application, for example, the binary bulk can be divided
into: 150 KByte application code, 300 KByte ET++
8. Implementing an Application Framework in C++ library, 400 KByte SunWindow libraries. When running
under UNIX several ET++ tools in parallel, the memory requirements
Using C++ as the implementation language of ET++ has are high. These memory problems are drastically reduced
worked extremely well. The well known efficiency of with the possibility to create shared libraries as included,
C++ was a very favorable background for the implemen- e.g., in Sun’s new operating systemrelease.
tation of ET++. Indeed, we never experienced efficiency
problems due to dynamic binding. In addition to the 9. Conclusions and Summary
object-oriented concepts C++ provides some other ET++ is an application framework based on the
features that improved the programming interface as well architecture of MacApp. It is smoothly integrated into a
as the code of ET++: Default arguments are often used in Unix environment with a conventional window system.
the constructors of ET++ classesand support both easy to All levels of the implementation use object-oriented
use but still flexible method interfaces. Operator techniques.The novel as@~tsdescribedin this paper were
overloading is another feature of C++ that was very useful an approach for handling composite objects and their
for implementing the two classes Point and declarative layout specification, classes for editable text
Rectangle. Operator overloading helped us to reduce allowing the integration of arbitrary interaction objects,
the bulk of code considerably and also improved its and finally a model to build hierarchies of scrollable
readability. The related feature of function overloading views.
was used mainly in constructors and is an elegant way to We believe that without applying object-oriented
provide alternative interfacesto create instancesof a class. techniquesit would not have been possible to implement a
The stream classesas provided by C++ proved to be system that comprises the functionality of the Macintosh
a very powerful abstraction. As shown in the foundation toolbox and of MacApp by only two programmersin just
classes,streamsprovided for a straightforward implemen- one year.

56 OOPSIA ‘88 Proceedings September25X41988


+12

10. Future Work bin871 Mark A. Linton, “Interviews Reference Manual


The starting point for our effort was to develop CASE- (Version 2-l),” Computer Systems Laboratory,
tools. We are now starting to work on tools for well Stanford University, September 1987.
known design methods such as entity-relationship B4=861 Rudolf Marty and Erich Gamma, ET - An
modeling. In the near future we are particularly interested Editor Toolkit for Bitmap-oriented
in tools and methodsfor object-oriented design. Workstations, 86, Institut fiir Informatik der
Another aspect that we want to study is the Universitit Ziirich, Ziirich, 1986.
integration of the ET++ application framework into a W@61 Norman Meyrowitz, “Intermedia: The
server-basedwindow system such as NeWSTM[Mic861 or Architecture and Construction of an Object-
X-Windows. One benefit of a server-based window Oriented Hypermedia System and Applications
system will be a further reduction in the size of the Framework,” OOPSLA’85, Special Issue of
executablemodules. NeWS supports dynamic loading of SIGPLAN Notices, vol. 21, no. Il. pp. 186-201,
client code into the server process, and we are interested Portland, Oregon, November 1986. ’
in what parts of an application framework cati be moved [Mic86] Sun Microsystems, Inc., NeWS Preliminary
into the server. Technical Overview, October 1986.

Acknowledgements [pa1881 Andrew J. Palay, Wilfred J. Hansen, Michael L.


Kazar, Mark Sherman, Maria G. Wadlow,
The authors would like to thank Peter Schnorf, Bruno Thomas P. Neuendorffer, Zalman Stem, Miles
Scmffer, Christoph Draxler, Karin Imholz and Anna Bader, and Thorn Pefers, “The Andrew Toolkit
Schlosser for their helpful comments on earlier versions - An Overview,” in Proc. EUUG, London, 7-9
of this paper. We are grateful to our early users - April, 1988.
Wolfgang Pree, HanspeterM&se&&k and Duri Schmidt
- for their tolerance working with an evolving [Rao87] Ram Rao and Smokey Wallace. “The’ X
experimentalsystem. Toolkit: The Standard Toolkit for X Version
11.” in USENIX Association Conference
References Proceedings (Atlanta, Georgia, June P-13). pp.
117-129, USENIX Assoc., El Cerrito, Calif.,
[App85] Apple Coniputer, Inside Macintosh Volume I, 1987.
Addison-Wesley, Reading, Mass., November [Ros86] Larry Rosenstein, Ken Doyle, and Scott
1985. Wallace, “Object-Oriented Programming for
[App86] Apple Computer, MucApp Programmer’s Macintosh Applications,” in ACM Fall Joint
Manual, Apple Computer, Inc., Cupertino, CA, Computer Science Conference, Dallas Texas,
November 1986. pp. 31-35, November 2-6.1986.
[Cox86] Brad J. Cox, Object Oriented Programming, [Sch86b] Robert W. Scheiffler tqd Jim Gettys, “The X
Addison-Wesley,Reading, Mass., 1986. Window System,” Transactions on Graphics,
[Go1831 Adele Goldberg and David Robson. SmaZltulk- vol. 5, no. 2, pp. 79-109, April 1986.
80, The Language and its Implementation, [Sch86] Kurt J. Schmucker. “Macapp: An Application
Addison-Wesley, Reading, Mass., November Framework,” Byte, vol. 11, no. 8, pp. 189-193,
1983. August 1986.
[Gor87] Keith E. Gorlen, “An Object-Oriented Class [Sch86a] Kurt J. Schmucker, Object Oriented
Library for C++ Programs,‘*Software--Practice Programming for the Macintosh, Hayden,
and Experience, vol. 17, no. 12, pp. 899-922, Hasbrouck Heights, New Jersey, 1986.
December 1987. [S&863 Mark Stefik and Daniel G. Bobrow, “Object-
[Han871 Wilfred J. Hansen, “Data Structures in a Bit- Oriented Programming: Themes and
Mapped Text Editor,” BYTE, vol. 12, no. 1, pp. Variations,” The AI Magazine, vol. 6, no. 4, pp.
183-189,January 1987. 40-62, Winter 1986.
[Ker75] B. W. Kemighan and L. L. Cherry, “A System [Yan88] Nicole Yankelovich, Bernard J. Haan, Norman
for Typesetting Mathematics,” Comm. Assoc. K. Meyrowitz, and Steven M. Drucker,
Comp. Much., vol. 18, pp. 151-157, Be11 “Intermedia: The Concept and the Construction
Laboratories, Murray Hill, New Jersey, March Of a SeamlessInformation Environment,” IEEE
1975. Computer, pp. 81-96, January 1988.

September2530,1988 OOPSLA‘88 Proceedings