\begindata{text,538375988}
\textdsversion{12}
\template{default}
\define{global
}
\formatnote{\chapter{Overview}}\indexi{Overview to the Toolkit}
The Andrew Toolkit (ATK) is a user interface toolkit with two primary goals:
(1) to support the development of stand-alone applications that integrate text, graphics and images in a standard, efficient user interface; and
(2) to support the development of multi-media editors, that is, editors that allow users to edit text, equations, graphs, tables, pictures, and so forth, all in a single program.
For example, Figure 1 depicts an Andrew Toolkit document containing both text and a picture.
(Figure inserted here)
Although the text and picture appear to be a single object, the text and the picture are actually separate objects that can be manipulated independently.
For example, if you pop-up the menus in the text region, you will see a full set of menus for editing text. If you pop-up the menus over the picture of the flamingo, however, you will see a different set of menus for editing the picture.
\formatnote{Figure: \formatnote{Andrew Toolkit document with pictureediting menus}
}In addition to allowing users to edit different types of objects in one place, the Andrew Toolkit supports the development of application programs that can include arbitrary objects upon demand. For example, \bold{ez}, the
Andrew Toolkit multi-media object editor, can dynamically load any object that has been created according to the Andrew Toolkit protocols. The editor does not need to know about the object in advance.
\section{Basic toolkit objects}\indexi{Basic Toolkit objects}

\subsection{Data objects and views}\indexi{Data objects} \indexi{Views}
The Andrew Toolkit provides a set of basic objects to use as building blocks for developing applications. Two of the most important of these objects are
\italic{data objects} and \italic{views}. A \italic{data object} contains the information to be displayed; a \italic{view} contains information about how the data is to be displayed and how the user will be able to interact with the data (e.g., via keyboard, menus, mouse, etc.). A \italic{data object}/\italic{view} pair is called an \italic{inset}. Insets are the normal basis for an Andrew Toolkit component. For example, in the figure showing the text editing menus, there are two insets, one for the text (text data object/text view) and one for the picture (picture data object/picture view).
The \italic{text data object} contains the actual characters (e.g.,
"This is a sample document."), style information (e.g., bold italics, etc.) and pointers to any embedded data objects (e.g., the picture data object of the flamingo); the \italic{text view} contains information such as the currently selected text, the portion of the text that is visible on the screen, and so forth, and also provides methods for drawing the text on the screen and handling various input events (keyboard, menus, mouse). Likewise, the
\italic{picture data object} contains the lines that make of the drawing, shading, and so forth; the \italic{picture view} provides methods for drawing the picture on the screen and handling various input events (keyboard, menus, mouse).
Both \italic{data objects} and \italic{views} have information (or data) associated with them. The information associated with a \italic{data object}, however, is information that you want to store between sessions, in a file
(e.g., the characters, style information, etc.), while the information associated with a \italic{view} is information that you consider transient, useful only during the run of the application program (e.g., the location of the text caret, the portion of text visible on the screen).
Note:\formatnote{<Of course, if you were building an application in which you wanted to save the state of the application between sessions, then you would want to store information such as the location of the text caret in a file as well.>}

While an Andrew Toolkit component normally consists of an inset (i.e., a data object/view pair), some components consist of only one of the two basic objects. For example, the \italic{scroll bar} in the previous figures has no data object; it consists only of a view that provides a user interface for controlling the display of the text view.
\subsection{Multiple views on a single data object}\indexi{Views++Multiple}\indexi{Data objects++Multiple views}
Separating \italic{data objects} and \italic{views} results in a major advantage: it is very easy to create applications in which there are multiple views of the same data object. For example, suppose you want to build a text editor that allows users to edit the same data in more than one window, with changes made in one window reflected in the other. In the Andrew
Toolkit, you would create two windows having two views of the same type (e..g, text views), displaying information from the same data object (e.g., text data object), an architecture actually employed by the Andrew Toolkit editor, \bold{ez}.
In addition to easily creating applications with two views of the same data object in two windows, you can also easily create applications with two different views on the same data object within the same window. For example, you might want to create an application that allows a user to display a set of numbers in a table and in a pie chart.
The capability of multiple views of the same data object is the reason for one of the unusual architectural features of the Andrew Toolkit: a delayed
"update protocol" for updating the screen in response to changes in the underlying data. In most systems, when a user issues a command to a view to alter the underlying data, Note:\formatnote{< Actually, the user issues a command to a component corresponding to an Andrew Toolkit view>} the view requests the data object to change, then updates the screen immediately, based on the information it has about what has changed. In the Andrew Toolkit, however, when a user issues a command to alter the underlying data object, only one view has the information about what should change, but there may be other views that need to reflect the change. Thus, a view first requests the data object to change, then requests the data object to inform all of its views that it has changed; when a view is informed that the underlying data object has changed, it does not have information about what has changed.
It

must first find out what the change is, then update the screen appropriately.
Thus, an application developer must develop a way for a view to determine which portion of the data object has changed. Normally, the developer builds a set of data object methods that provide the information to views upon request.
\section{Event processing}\indexi{Overview++Event processing}
\subsection{The interaction manager}\indexi{Interaction manager}
The Andrew Toolkit is an event-driven system. The Andrew Toolkit provides a component, the \italic{interaction manager}, that translates input events such as key strokes, mouse events, menu events, and so forth, from the underlying window system to \italic{views}. The \italic{interaction manager} also synchronizes drawing requests among views.
The \italic{interaction manager} hides the input model used by the underlying window system from application developers, making Andrew Toolkit applications more portable. For example, Andrew Toolkit runs under two window managers,
X.11 and The Andrew window manager, \italic{wm}. \indexi{Window manager}
\subsection{The view tree}\indexi{View tree hierarchy}
The \italic{Interaction Manager} is at the root of a tree of
\italic{views}, called the \italic{view tree}. There is one \italic{interaction manager} per window. The \italic{interaction manager} has one child view, which can be a view of any type. The child view, in turn, can have any number of children.
Each view has screen space allocated to it. The screen space allocated to child views must always be contained within the screen space allocated to their parent views, but the Toolkit allows any screen relationship among sibling views. Figure 3 depicts the screen image from the previous figure on the left and on the right, the corresponding \italic{view tree}. The dotted lines around parts of the screen image represent the screen space allocated to each associated view. The \italic{interaction manager} is at the top of the
\italic{view tree}. It has a single child view, a \italic{frame}, which is an
Andrew Toolkit component that provides a user message line and dialog

facility. Because it is the immediate child of the \italic{interaction manager}, it is allocated screen space that corresponds to the entire window.
The \italic{frame view} has two children, a \italic{scroll bar view} and a
\italic{message line view}. The \italic{scroll bar view} has a single child, a \italic{text view}, which in turn has a single child, a \italic{picture view}. The \italic{text} and \italic{picture} views have corresponding
\italic{data objects}, which are also depicted.
\formatnote{Figure 3: \formatnote{Andrew Toolkit View Tree
}}
In general, when an \italic{interaction manager} receives an event, usually from the underlying window manager, it passes the event down to its child view. That view either processes the event or passes it down to one of its children. The views continue to pass the event down the view tree until some view actually handles the event. Suppose, for example, that the
\italic{interaction manager} in Figure 3 receives a mouse event. It passes the event down to its child, the \italic{frame view}. If the mouse event is close to the dividing line between its two children, the frame processes the mouse event, interpreting it as a user request to adjust the position of the dividing line between the text and the message line; otherwise, the
\italic{frame} passes the event down to the \italic{message line view}, provided the mouse event occurred within the screen space allocated to it, or to the \italic{scroll bar view}. If the mouse event occurred in the screen space over the scroll bar, the \italic{scroll bar view} processes the event; otherwise, it passes it to the \italic{text view}. If the mouse event occurred outside the \italic{picture view}, the \italic{text view} processes the event; otherwise, it passes it to the \italic{picture view}.
Unlike other user interface toolkits, the Andrew Toolkit passes events down the view tree, rather than passing them directly to a view based on screen allocation. Processing based on the view tree architecture provides more flexible handling of events. For example, in toolkits based on screen allocation, if one component is physically on top of another component, it will block the transmission of events to the lower component. While this behavior is valid in many circumstances, there are times when it is inappropriate. Another example is provided by the \italic{frame view}, which divides its image into two areas separated by a thin line. In order to allow

the user to adjust the line easily, the frame accepts mouse events in an area slightly larger than just the thin line, an area that thus overlaps the space allocated to the frame's children. In a toolkit in which event processing is based on screen allocation, providing the ability to adjust the line easily is more difficult, requiring \italic{views} to have detailed knowledge of the view tree structure. In the Andrew Toolkit, on the other hand, a view only needs to know about the location of its children. It does not even need to know the child's type. Likewise, the child needs no knowledge about the its parent's type or its location in the overall view tree.
Updates to the screen are also handled through the view tree architecture.
When a view wants to update its image, it does not simply re-draw the screen.
Instead, it makes a request for an update to its parent view. That request is passed up to the \italic{interaction manager} which then sends an update event down the tree. When the parent receives the update event, it can update its image and its children's images in the appropriate order. For example, the parent might have overlaid some other image on top of the child's image and would first update the child, then the other image. For example, a drawing editor may have overlaid a line on top of some text.
\section{Window system independence}\indexi{Window systems}
The Andrew Toolkit provides a graphics layer that hides the output model of the underlying display, usually an underlying window system or a printer.
\section{File representation}\indexi{File representation}
In order to support the inclusion of arbitrary objects in multi-media editors, the Andrew Toolkit requires data objects to conform to a set of conventions for their file representation. A \italic{data object} must write its data enclosed in a begin/end marker pair. The marker must include a tag denoting the type of the object being written and a unique identifier, used for referencing the data object by other data objects. If a data object includes other data objects, they must be properly nested. The begin/end markers make it possible to find the data associated with an object without actually

parsing the data.
For example, Figures 1 and 2 have the file representation depicted in
Figure
4.
Figure 4: \formatnote{\formatnote{Andrew Toolkit File Representation}
\leftindent{\example{
\\begindata \{text, 1\}
\italic{<text data>}
\\begindata \{picture, 2\}
\italic{<picture data>}
\\enddata \{picture, 2\}
\italic{<text data>}
\\view \{pictureview, 2\}
\italic{<text data>}
}
}
}The Andrew Toolkit requires the begindata/enddata format. Most Andrew
Toolkit applications also follow conventions that make the files more transportable and more robust. In order to transport files across most networks, application developers should also use only printable 7-bit
ASCII characters, including tab, space and new-line, and keep line lengths below 80 characters. Of course, some objects cannot follow the first convention, for example, raster images. In order to facilitate data recovery, the file representation should be understandable.
\section{The Object-oriented programming environment}\indexi{Objectoriented programming} \indexi{Class system}
The Andrew Toolkit is written using the Andrew Class System (Class), an
\italic{object-oriented programming environment}.
\subsection{Objects, classes and instances}\indexi{Objects}
\indexi{Class++Instance}
An \italic{object} is simply a structure capable of representing the two fundamental capabilities of a computer: storing data and carrying out operations on data.

In an object-oriented system, it is useful to group all the objects that share the same data structures or procedures that manipulate the data. Such a group of objects is called a \italic{class}. Objects that are in a class are called
\italic{instances} of the class.
Suppose an object \italic{L1} represents the list \italic{(a b c)} and object
\italic{L2}, the list \italic{(d e f)}. Both can be usefully grouped as instances of a class \italic{list}. Even though each object has different data, they share the same data structure as well as the procedures for operating on their data.
\subsection{Class procedures, methods and data}\indexi{Class procedures}
\indexi{Methods} \indexi{Data}
Each class has a set of \italic{class procedures}, \italic{methods} and
\italic{data}.
There are a small number of operations that are general to all objects within the system. For example, there must be operations for creating and destroying an instance of a class. These operations, as well as any operations that are specific to the class rather than to instances of the class, are called
\italic{class procedures}. Classes \italic{must} provide the general class procedures (e.g., create an instance of a class, delete an instance of a class) and may provide others specific to the class (e.g., initialize some data in the class).
Along with the set of general class procedures that each class must provide, a class may provide a set of specific operations, called \italic{methods}, which are operations that an object carries out, usually on its data. For example, a class for text might have methods for inserting a string, deleting characters and returning the characters at a given position.
The \italic{data} for a class is a collection of one or more variables which may be structured for convenient processing. For the text class, such data might include a variable for character strings, a variable for document length and another variable for indicating if the text if "read only" or not.

\subsection{Subclasses and superclasses}\indexi{Superclass}
\indexi{Subclass}
Classes can have subclasses and superclasses. When you create a subclass of a class, you do not need to re-specify the data and methods that the subclass shares with its parent class, or superclass. Unless you specify otherwise, via a set of statements that \italic{override} the superclass' specification, the subclass simply inherits the data and methods from its superclass.
Classes do not inherit class procedures since those are specific to the class. In addition to the inherited data structures and operations, a subclass can add new data structures and new methods. It can also override methods that it would also inherit from the superclass.
The relationships between classes go beyond a single parent-child link.
A class inherits not only all the data and methods from its immediate parent, but also the data and methods from the parent's parent, and so on through the complete \italic{class hierarchy} of classes and superclasses. Of course, a descendant class would not inherit methods that have been overridden by an ancestor.
\subsection{Requests}\indexi{Requests}
An object (i.e., an instance of a class) will carry out one of its operations when another object invokes one of its methods or class procedures. Each object maintains a list of the set of requests that it has methods or class procedures for carrying out. The requests that any given object understands depend, of course, on what the object is intended to represent. If an object represents a list, then the the object should understand requests to add another element to the front of a list, delete an element from a list, and so forth; if an object represents a text-editor, then the object should understand requests to display text on the screen, respond to a user's mouse click, and so on.
Conceptually, when another object issues a request to an object, the system searches the methods in the object's class. If the method is not found, they system searches in the class' superclass. The search continues up the superclass chain until a matching method is found or until the root of the

class hierarchy is reached. If the method is not found by that time, an error is reported to the programmer at load time.
The Andrew Toolkit's stratagem for finding methods insures that the most
"recent" version of the method code is executed. For example, suppose the class \italic{view} defines a method named \italic{FullUpdate}, and class
\italic{view} has a subclass \italic{textview}, and class
\italic{textview} has a subclass named \italic{typescriptview}. Ordinarily, if
\italic{typescriptview} calls method \italic{FullUpdate}, then the system searches first in \italic{typescriptview}, then in \italic{textview}, then finally in \italic{view} and executes the code for \italic{FullUpdate} as defined in class \italic{view}. But suppose class \italic{textview} has overridden the method \italic{FullUpdate}. Now, if
\italic{typescriptview} calls \italic{FullUpdate}, the code as defined in the override in class
\italic{textview} is executed, \italic{not} the original code for
\italic{FullUpdate} in class \italic{view}.
\section{Application programming in the Andrew
Toolkit}\indexi{Application programs}
When developing new classes, application programmers must follow a set of guidelines, detailed in the rest of this volume. If you follow these guidelines, then instances of the class can be included in any other application program or multi-media editor that has been developed to manage arbitrary objects. An object can be placed inside another object without either one having specific information about the other. The only piece of information that the enclosing object must have about the enclosed object is its name.
Using only the general procedures we can build a mechanism for embedding one object within another and create hierarchies of objects. Consider a document that contains both some text, a line drawing and an equation. The interactions between the text objects, the line drawing object, and the equation object are all done via the general procedures. Thus, you can write your own support packages to work with the general procedures instead of relying on such packages to be written by system developers.
\section{Dynamic loading} \indexi{Dynamic loading}
Programs written in high-level languages usually must go through several translation processes before they can be executed. The following is the typical sequence for C programs: (1) the C \italic{preprocessor} translates

to standard C; (2) The C \italic{compiler} takes the C language source program and translates it to the assembly or machine language of an actual machine
(e.g., IBM RT, SUN 2, etc.); (3) the \italic{linking loader} links the various modules and fills in external data and module addresses appropriately.
The result is the final executable program.
In standard systems, the linking loader must be run before the program can be executed. In contrast, the Andrew Class System supports dynamic loading of objects, that is, loading objects after the main program has started executing. Dynamic loading allows multi-media editors to load arbitrary objects that users request and is a key element of the Andrew Toolkit.
\begindata{bp,537558784}
\enddata{bp,537558784}
\view{bpv,537558784,1084,0,0}
Copyright 1992 Carnegie Mellon University and IBM. All rights reserved.
\smaller{\smaller{$Disclaimer:
Permission to use, copy, modify, and distribute this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice, this permission notice, and the following disclaimer appear in supporting documentation, and that the names of
IBM, Carnegie Mellon University, and other copyright holders, not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.
IBM, CARNEGIE MELLON UNIVERSITY, AND THE OTHER COPYRIGHT HOLDERS
DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT
SHALL IBM, CARNEGIE MELLON UNIVERSITY, OR ANY OTHER COPYRIGHT HOLDER
BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS

ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
OF THIS SOFTWARE.
$
}}\enddata{text,538375988}