COMPUiER SYSTEMS LABORATORYI ISTANFORO UNIVERSITY . STANFORD, CA 94305-4055

Unidraw: A Framework for BuildingDomain-Specific Graphical Editors

John M. V&sides and Mark A. Linton

Technical Report: CSL-TR-89-380

July 1989

Research supported by the NASA CASIS project under ContractNAGW 419 and by the Quantum project through a gift fromDigital Equipment Corporation. -

Unidraw: A Framework for BuildingDomain-Specific Graphical Editors

John M. Vlissides and Mark A. Linton

Technical Report: CSL-TR-89-380

July 1989

Computer Systems LaboratoryDepartments of Electrical Engineering and Computer Science

Stanford UniversityStanford, CA 94305

Abstract

Unidraw is a framework for creating object-oriented graphical editors in domains such as technicaland artistic drawing, music composition, and CAD. The Unidraw architecture simplifies theconstruction of these editors by providing programming abstractions that are common acrossdomains. Unidraw defines four basic abstractions: components encapsulate the appearanceand behavior of objects, tools support direct manipulation of components, commands defineoperations on components, and external representations define the mapping between componentsand a file or database. Unidraw also supports multiple views, graphical connectivity, and dataflowbetween components. This paper presents Unidraw and three prototype domain-specific editorswe have developed with it: a schematic capture system, a user interface builder, and a drawingeditor. Experience indicates a substantial reduction in implementation time and effort comparedwith existing tools.

Key Words and Phrases: Object-oriented graphical editors, direct manipulation user interfaces,graphical constraints.

Copyright @ 1989

bY

John M. Vlissides and Mark A. Linton

Unidraw: A Framework for BuildingDomain-Specific Graphical Editors

John M. Vlissides and Mark A. LintonStanford University

AbstractUnidraw is a framework for creating object-orientedgraphical editors in domains such as technical andartistic drawing, music composition, and CAD. TheUnidraw architecture simplifies the construction ofthese editors by providing programming abstractionsthat are common across domains. Unidraw definesfour basic abstractions: components encapsulate theappearance and behavior of objects, tools support di-rect manipulation of components, commands defineoperations on components, and external representa-tions define the mapping between components and aEle or database. Unidraw also supports multiple views,graphical connectivity, and dataflow between components. This paper presents Unidraw and three proto-type domain-specific editors we have developed withit: a schematic capture system, a user interface builder,and a drawing editor. Experience indicates a substan-tial reduction in implementation time and effort com-pared with existing tools.

Keywords: object-oriented graphical editors, directmanipulation user interfaces, graphical constraints

1 IntroductionGraphical editors represent familiar objects visuallyand allow a user to manipulate the representations di-rectly. Unfortunately, these editors are difficult to buildwith general user interface tools because of the specialrequirements of graphical editors. For example, userinterface toolkits provide buttons, scroll bars, and waysto assemble them into a specific interface, but they donot offer primitives for building drawing editors thatproduce PostScript or schematic capture systems thatproduce netlists. Higher-level abstractions are requiredto make such editors easier to implement.

We use the term graphical object editor for an ap-plication that lets users manipulate graphical represen-

This research has been supported by the NASA CASIS projectunder Contract NAGW 419 and by the Quantum projea through agift from Digital Equipment Corporation.

To appear in the Proceedings of the ACM SIGGRAPH/SIGCHIUser Interface Software and Technologies ‘89 Conference, Williams-burg, Virginia, November 1989.

tations of domain-specific objects and generates oneor more static representations. Most graphical objecteditors also feature

non-interactive operations, usually invoked frommenus, that affect objects’ state;

structuring techniques for building hierarchies ofobjects;

mechanisms for propagating information andmaintaining graphical constraints between ob-jects;

and a persistent representation to store objects innon-volatile form.

Unidraw is a collection of programming abstractionsthat simplifies the construction of graphical object ed-itors. Unidraw reduces the time it takes to produce aneditor for a domain by providing functionality char-acteristic of graphical object editors; it does not of-fer toolkit features (it is used in conjunction with atoolkit), nor does it assume the role of a program de-velopment environment (it provides objects that areused within an existing environment). In this paper wepresent the Unidraw architecture and discuss our pro-totype implementation, including a brief description ofthree editors we have built with the Unidraw prototype:a schematic capture system, a direct-manipulation userinterface builder, and an object-oriented drawing editorsimilar to MacDraw.

2 Related WorkWe can divide current systems that support graph-ical object editing into three categories: domain-specific editors, multi-domain systems, and graphi-cal programming environments. Domain-specific edi-tors are stand-alone applications designed for editingin a particular domain. Object-oriented drawing edi-tors such as MacDraw are the most common example.Other examples are

l computer-aided design (CAD) tools that providea direct manipulation metaphor for producing de-sign specifications, such as VLSI layout editors

-2-

for creating chip masks and schematic capturesystems for generating netlists;

l diagram editors [5, 7J that specify, model, anddocument physical or mathematical processeswith graphical notations such as finite-state di-agrams and petri nets;

l and user interface editors that let nonprogrammersassemble a user interface by direct manipulationand then generate the source code for the inter-face.

“Multi-domain” is a catch-all term for systems thatare neither tied to a particular domain nor designed tosupplant traditional programming languages, as graph-ical programming environments are. Examples ofmulti-domain systems include user interface toolkitssuch as Interviews [6] and GROW [2] that supportdefinition and manipulation of an editor’s graphicaldata; simulation systems [4, l] that provide a direct-manipulation metaphor for representing and analyz-ing real-world processes in areas such as data acqui-sition, manufacturing, and decision support; and gen-eral constraint-based graphical editors such as Sketch-pad [9] and ThingLab [3], which can theoretically sup-port graphical editing in any domain given enoughconstraints.

Graphical programming environments [8] let usersprogram by drawing pictures. Experienced program-mers often use graphical notations to diagram theiralgorithms before turning them into code. Novicesoften find programming difficult because they are un-comfortable with the rigid syntax of textual languages.By specifying programs in graphical terms that closelymatch the programmer’s mental pictures, the expertcan simply draw his algorithms; the novice can showthe computer how to perform its task. Graphical pro-gramming environments would thus make program-ming easier for everyone, and creating domain-specificeditors would be a natural extension of their capabili-ties.

Our work with Unidraw focuses on production-quality domain-specific editors for a broad range ofdomains. Each of the approaches described abovefalls short of this goal. Domain-specific editors aredesigned to support a single domain only. Existingmulti-domain systems have at least one of the follow-ing shortcomings:l They provide relatively few abstractions for

building domain-specific editors. For example,one toolkit might offer structured graphics but notgraphical constraints, while another supports con-straints but not static representations, and so on.

User interface toolkit

Operating sy*tem

Figure 1: Layers of software underlying a domain-specific editor

0 They require a large run-time environment or areembedded in a larger system. Thus they cannotbe used to create stand-alone editors.

l The extension mechanism for multiple domains isnot efficient enough to be practical. For example,a fast general constraint solver is hard to imple-ment. Developing a domain-specific editor thathas acceptable performance is therefore difficultwhen constraints are the only extension mecha-nism.

Graphical programming environments have proven in-adequate as well. Though many such environmentshave been developed, none has succeeding in supplant-ing textual programming. Graphical languages gener-ally lack efficiency of expression. They are adequatefor describing simple algorithms and data structuresbut quickly become unwieldy for specifying more so-phisticated constructs. Moreover, most graphical pro-gramming systems are interpretive and must deal withconsiderable overhead associated with pictorial repre-sentations. Thus, performance is acceptable only forsimple programs.

3 Unidraw ArchitectureUnidraw is designed to span the gap between tradi-tional user interface toolkits and the implementationrequirements of graphical object editors. An editor fora particular domain relies on Unidraw for its graph-ical editing capabilities, on the toolkit for the “lookand feel” of the user interface, and on the window andoperating systems for managing workstation resources.

-3-

Figure 1 depicts the dependencies between the lay-ers of software that underlie a domain-specific editorbased on Unidraw. At the lowest levels are the oper-ating and window systems. Above the window sys-tem level are the abstractions provided by the toolkit,including buttons, scroll bars, menus, and techniquesfor composing them into generic interfaces. Unidrawstands at the highest level of system software, pro-viding abstractions that are closely matched to the re-quirements of graphical object editors. In theory, adomain-specific editor can access any of these layers;in practice, minimizing the number of software inter-faces the programmer must use dramatically reducescomplexity.

3.1 OverviewUnidraw partitions the common attributes of domain-specific editors into an object-oriented architecturehaving four class hierarchies:

1. Components are graphical representations of el-ements in a domain. Examples include geometricshapes in technical drawing, electronic parts incircuit layout, and notes in written music. Com-ponents encapsulate the appearance and behaviorof these elements. A domain-specific editor’s pur-pose is to allow the user to arrange componentsto convey information in the domain of interest.

2. Tools support direct manipulation of components.Tools employ animation and other visual effectsfor immediate feedback to reinforce the user’sperception that he is dealing with real objects.Examples include tools for selecting componentsfor subsequent editing, for applying coordinatetransformations such as translation and rotation,and for connecting components.

3. Commands define operations on components andother objects. Commands are similar to mes-sages in traditional object-oriented systems, ex-cept they are stateful and can be executed as wellas interpreted by objects, Commands can also bereverse-executed, allowing rollback to a previousstate. Examples include commands that changecomponent attributes, duplicate components, andgroup several components into a composite com-ponent.

4. External representations are used to conveydomain-specific information outside the editor.Each component can define one or more externalrepresentations of itself. For example, a transistor

component can define both a PostScript represen-tation for printing and a netlist representation forcircuit simulation.

The Unidraw architecture provides base classes forcomponent, command, tool, and external representa-tion objects. Subclasses implement the behavior oftheir instances according to the semantics of the protocol defined by their base class. For example, com-ponents support operations that define how commandsaffect their internal state.

3.1.1 Subjects and Views

A well-established user interface concept is the distinc-tion between (1) the state and operations that charac-terize objects and (2) the way the objects are presentedin a particular context. In Unidraw this distinction ismanifest in the separation of components into sub-ject and view objects. A subject defines the context-independent state and operations of a component. Aview supports a context-dependent presentation of thesubject. A component subject may have one or morecomponent views, each offering a different representa-tion of and interface to the subject. A subject notifiesits views whenever its state is modified to allow themto change their state or appearance to reflect the mod-ification.

A component subject maintains information thatcharacterizes the component; in the case of a logic gatecomponent, for example, the subject might contain in-formation about what is connected to the gate and itscurrent input values. Different views of the subjectcan reflect this information in distinctive ways and canprovide additional information as well. One view candepict the gate graphically by drawing the appropriatelogic symbol, and it might also define what it meansto manipulate the gate with a tool. Another view canprovide the external representation of the gate by gen-erating a netlist from the connectivity information inthe subject.

3.1.2 Application Framework

Figure 2 shows the general structure of a domain-specific editor based on Unidraw. At the bottom levelin the diagram are two component subjects, the left-most containing subcomponent subjects. An entiredomain-specific drawing :Is represented by a compos-ite component subject that can be incorporated into alarger work. At the second level from the bottom arethe corresponding views of the subjects. Note that theright-hand subject has two views attached. Each com-ponent view is placed in a viewer at the third level.

4-

Figure 2: General structure of a domain-specific editorbased on Unidraw

A viewer displays a graphical component view, mostoften the root view in a hierarchy. A viewer pro-vides a framework for displaying the view, supportingsuch “non-semantic” manipulations as scrolling andzooming. Viewers also take raw window system ortoolkit events and translate them to conform to stan-dard Unidraw protocols.

An editor associates tools and user-accessible com-mands with one or more viewers and combines theminto a coherent user interface. An editor also main-tains a selection object that manages component viewsin which the user has expressed interest. A Unidraw-based application can create any number of editor ob-jects, allowing the user to work on multiple views ofcomponents. Operations requiring inter-editor com-munication or coordination access the unidraw object,a one-of-a-kind object maintained by the application.For example, commands that allow the user to openand close editors and quit the application must accessthis object. The unidraw object also maintains logsof commands that have been executed and reverse-executed to support arbitrary-level undo and redo. Notshown in the diagram is the catalog object, whichmanages a database of components, commands, andtools. At minimum, a domain-specific editor uses thecatalog to name, store, and retrieve components thatrepresent user drawings. An editor could also accessunused commands and tools and incorporate them intoits interface at run-time.

This structure provides a standard framework forbuilding domain-specific editors, yet it allows substan-tial latitude for customized interfaces. Nothing in this

return values operation argumentsAttach camp. viewDetach camp. viewNot@updateInterpret commandUninterpret command

transfer fn. GeffransferFunction(child iterationand manipulationoperation)

graphic GetGraphicSetMobility mobility

mobility GetMobility

Table 1: Component subject protocol

architecture dictates, for example, a particular look andfeel for a given editor object. A domain-specific editormay define editor objects that use separate windows fortheir commands, tools, and viewers. The architectureonly specifies how the editor mediates communicationbetween components and the commands, tools, andviewers that affect them.

3.2 ComponentsA component defines the appearance and behavior ofa domain-specific object A component’s behavior hasthree aspects: (1) how it responds to commands andtools, (2) its connectivity, and (3) how it communi-cates with other components. This section describesthe protocols and abstractions that support componentsemantics.

3.2.1 Subject and View Protocols

The Unidraw architecture defines separate protocolsfor component subjects and views. Tables 1 and 2 listthe protocols’ basic operations. Component subjectsdefine Attach and Detach operations to establish ordestroy a connection with a component view. Notifyalerts the subject’s views to the possibility that theirstate is inconsistent with the subject’s Upon notifica-tion, a view reconciles any inconsistencies between thesubject’s state and its own. The Update operation isused to notify the subject that some state upon whichit depends has changed. The subject is responsible forupdating its state in response to an Update message.

A component subject can be passed a command tointerpret via the Interpret operation. The semanticsof this operation are component-specific; the subject

return values

graphic

manipulatorcommand

operation

InterpretUninterpret{child iterationand manipulationoperation)GetGraphicHighlightUnhighlightCreateManipulatorInterpretManipulator

commandcommand

tool, eventmanipulator

Table 2: Component view protocol

typically retrieves information from the command forinternal use or executes the command. The Uninterpretoperation allows the component to negate the effectsof a command; the subject might undo internal statechanges based on information in the command, or itmight simply reverse-execute the command. Compo-nents can also define a transfer function, described inSection 3.2.4, that can be accessed via the GetTrans-ferFunction operation. Finally, a component subjectcan contain other component subjects, allowing hier-archies of domain-specific components. Componentsubjects therefore define a family of operations for it-erating through their child subjects (if any) and forreordering them.

The component view protocol duplicates some ofthe subject protocol’s operations, namely Update, In-terpret, Uninterpret, and those for child iteration andmanipulation. A subject’s Notify operation usuallycalls Update on each of its views. Interpret and Unin-terpret are defined on views because some objects ma-nipulate component views rather than their subjects.Thus it may be convenient to send a command to aview for (un)interpretation, which may in turn send itto its subject. A component view may have a subcom-pot-rent view structure, which may or may not reflectits subject’s structure, so the view protocol also defineschild iteration and manipulation operations.

Graphical components are specialized componentsthat use graphic objects in both their subjects andviews to define their appearance. A graphic containsgraphics state and geometric information and uses thisinformation to draw itself and to perform hit detection.By definition, graphical component subjects store theirgeometric and graphics state in a graphic, providing astandard interface for retrieving this information. TheGetGraphic operation returns the information in the

subject’s graphic. Graphical component subjects canalso have a mobility attribute and define operations forassigning and retrieving it. Later we show how mo-bility is used to define the component’s connectivitysemantics.

Several operations augment the basic componentview protocol to support graphical component views.These views maintain a graphic that defines their ap-pearance, so they provide a GetGraphic operation.Highlight and Unhighlight operations let views distin-guish themselves graphically, for example, when theyare selected. CreateManipulator and Interprethknip-ulator define how a graphical component view reactswhen it is manipulated by a tool and how the toolaffects the component after manipulation. Both op-erations use a manipulator to characterize the ma-nipulation. Manipulators abstract and encapsulate themechanics of direct manipulation; they are discussedfurther in Section 3.4.

3.2.2 Connectors

Unidraw supports connectivity and confinement se-mantics with the connector graphical component sub-class. Since connectors are components, each consistsof a subject and zero or more views and can be manip-ulated directly. Often, however, connectors are embed-ded in larger components that use connector subjectsto define their own connectivity semantics but do notincorporate the corresponding connector views in theirown views.

A connector can be connected to one or more otherconnectors. Once connected, two connectors can af-fect each other’s position in specific ways, as definedby the semantics of the connection. Connector subclasses support different connection semantics. A pincontributes zero degrees of freedom to a connection.A degree of freedom is an independent variable alonga particular dimension, which for connectors is a carte-Sian coordinate. Slots and pads provide one and twodegrees of freedom within certain bounds, respectively.

Figure 3 shows how different connectors behavein several connections, using the connectors’ defaultgraphical representations. The centers of two con-nected pins must always coincide (Figure 3a). A pinconnected to a slot (Figure 3b) is free to move alongthe slot’s major axis until it reaches either end of theslot; the pin cannot move in the transverse dimension.Two connected slots (Figure 3c) can move relative toeach other as long as the center lines of their majoraxes share a point. Finally, Figure 3d shows how apad-pin connection constrains the pin to stay withinthe confines of the pad

- 6 -

m

Figure 3: Several connections and their semantics

The connectors’ mobilities characterize how eachconnector moves to satisfy the connection constraints.A mobility attribute can have one of three values:fixed, floating, or undefined. In general, a fixed com-ponent’s position cannot be affected by a connectionregardless of the connection’s semantics, while a float-ing component will move to satisfy the connection’ssemantics. The behavior of a connector with undefinedmobility is indeterminate. Composite components of-ten have undefined mobility to avoid overriding theirchildren’s mobilities.

Mobility specifications disambiguate the semanticsof a connection. In Figure 3b, for example, it is unclearwhich connector (the pin or the slot) actually moves.If, however, the slot’s mobility is fixed and the pin’s isfloating, then the pin will always move to satisfy theconnection constraints. If the slot is moved explicitly,then the pin will move to stay within it. An attempt toexplicitly move the pin beyond the slot’s bounds willfail; in fact, if the pin is also connected to another,orthogonal slot, any attempt to move it explicitly willfail. As a corollary, a connection can have no effecton two fixed connectors.

3.2.3 Domain-Specific Connectivity

Domain-specific components use connectors to definetheir connectivity semantics. For example, consider

hvutr

, hvortrsubjoet

Figure 4: Possible composition of an inverter compo-nent

an inverter schematic component whose wires remainconnected when the user moves it. Figure 4 showshow the inverter subject and view can be composedwith polygon, circle, and pin subjects and views. Notethat the pins are treated as any other component in thecomposition, but they have a special responsibility todefine the inverter’s connectivity semantics. The in-verter gives its pins fixed mobility so that their posi-tions are unaffected by any connections to them. Whenthe inverter is moved, it moves all its components.Since the pins are fixed, they will not be affected bytheir connections; rather, any floating connectors thatare connected to the pins will move as the connectionpermits. One such floating connector might be a pinsubcomponent of a wire component whose shape is de-termined by the position of the pin; the wire thereforedeforms to maintain the connection. Graphical com-ponents can thus extend the connectivity behavior ofprimitive connectors to define their own connectivitysemantics.

3.2.4 Dataflow

Communication between components is often tiedclosely to their connectivity. Unidraw provides a stan-dard way for components to communicate via dataflowand for associating dataflow with their connectivity.

Component subjects often maintain state on whichother subjects depend or state that must be accessibleto the user. Unidraw defines a set of objects calledstate variables that provide a standard way to rep-resent and access this state. State variables are com-monly used to allow user modification of componentattributes and to support dataflow between compo-nents. Like components, state variables are partitionedinto subjects and views. The state variable subject

7-

represents a typed datum, and views provide a graph-ical interface that lets a user examine and modify thesubject. A component can make its state variablesavailable externally by providing access operations asnecessary.

A state variable can be bound to a connector like anactual parameter is bound to a formal parameter in aprocedure call Connectors define “parameter passing”semantics for any bound state variable, one of in, out,or inout. When connected, two connectors with boundstate variables will pass their values accordingly; forexample, an in connector’s state variable will receivethe value of an out connector’s variable. Passing avalue between incompatible connectors (such as twoout connectors) is an error; such connections shouldbe disallowed by the tool or command making theconnection.

Transfer functions complete the dataflow model byparticipating in the propagation of state variable val-ues. A transfer function defines a relationship betweenstate variables, modifying one set of variables basedon the values of another set. For example, the invertercould use an Inverf transfer function to establish a de-pendency between the logic level state variables boundto its in and out pins: Invert assigns the inverse valueof the input variable to the output variable. Thus trans-fer functions describe how values change as they flowfrom one component to another.

3.3 Commands

Commands are analogous to messages because theycan be interpreted by components. Commands are alsolike methods in that they are stateful and can be ex-ecuted, and they resemble transactions because theycan be reverseexecuted to a previous state. Somecommands may be directly accessible to the user asmenu operations, while others are only used by theeditor internally. In general, any undoable operationsshould be carried out by command objects.

Table 3 shows the basic operations defined by thecommand protocol. Execute performs computation tocarry out the command’s semantics. Unexecute per-forms computation to reverse the effects of a previousExecute, based on whatever internal state the com-mand maintains. A command is responsible for main-taining enough state to reverse one Execute operation;repeated Unexecute operations will not undo the ef-fects of more than one Execute. Multilevel undo canbe implemented by keeping an ordered list of com-mands to reverseexecute. It may not be meaningful orappropriate, however, for some commands to reverse

return values operation7

CU$pU?WltS

ExecuteUnexecute

boolean ReversibleStore camp. subj., any

mY Rf%Xll camp. subj.SetClipboard clipboard

clipboard GetClipboard(child iterationand manipulationoperations}

Table 3: Command protocol

their effect. For example, it is probably not feasible toundo a command that generates an external represen-tation. The Reversible operation indicates whether ornot the command is unexecutable and uninterpretable.If the command is not reversible, then it can be ignoredduring the undo process.

Since a command can affect more than one compo-nent, the command protocol must allow componentsthat interpret the command to store information in itthat they can later use to reverse its effects. The Storeoperation allows a component to store information inthe command as part of its Interpret operation. Thecomponent can retrieve this information later with theRecall operation if it must uninterpret the command.Furthermore, commands that operate on selected orotherwise distinguished components must maintain arecord of the component subjects they affected and theorder in which they were affected. Commands there-fore store a clipboard object, which can be assignedand retrieved with the SetClipboard and GetClipboardoperations. A clipboard keeps a list of component sub-jects and provides operations for iterating through thelist and manipulating its elements. Typically, the clip-board is initialized with the component subjects whoseviews are currently selected when the command is tistexecuted. Purely interpretive commands should de-fine their Execute and Unexecute functions to invokeInterpret and Uninterpret on the components in theirclipboard.

It is often convenient to create “macro” commands,that is, commands composed of other commands. Thecommand protocol includes operations for iteratingthrough and manipulating its children, if any. By de-fault, (un)executing or (un)interpreting a macro com-mand is semantically identical to performing the cor-responding operations on each of its children.

Table 4: Tool protocol

3.4 ToolsBy definition, a graphical object editor supports the di-rect manipulation model of interaction. Unidraw-basededitors use tool objects to allow the user to manipulatecomponents directly. The user grasps and wields a toolto achieve a desired eflect. The effect may involve achange to one or more components’ internal state, or itmay change the way components are viewed, or theremay be no effect at all (if the tool is used in an inappro-priate context, for example). Tools often use animatedgraphical effects as they are wielded to suggest howthey will affect their environment.

3.4.1 Tool Protocol

The basic tool protocol is shown in Table 4. Con-ceptually, tools work within viewers, in which graph-ical component views are displayed and manipulated.Whenever a viewer receives an event, it in turn asksthe current tool (defined by the enclosing editor ob-ject) to produce a manipulator object. A tool imple-ments its CreateManipulator operation to create andinitialize an appropriate manipulator, which encapsu-lates the tool’s manipulation semantics by defining thethree phases (grasp, wield, effect) of the manipulation.A tool may modify the contents of the current selec-tion object (also defined by the enclosing editor) basedon the event. Moreover, a tool can delegate manipula-tor creation to one or more graphical component views(usually among those in the editor’s selection object) toallow component-specific interaction. A tool’s Inter-pretManipulator operation analyzes information in themanipulator that characterizes the manipulation andthen creates a command that carries out the desiredeffect. If the tool delegated manipulator creation toa graphical component view, then it must delegate itsinterpretation to the same view.

The GetPrototype operation is defined by the graph-ical component tool subclass. Graphical componenttools maintain a prototype component and define howthat component is created and added to the componenthierarchy in the viewer. The prototype consists of botha graphical component subject and a view. The tool

return values operation argumentsGrasp event

boolean Manipulating eventEffect event(child iterationand manipulationoperations)

1

Table 5: Manipulator protocol

copies the prototype, modifies it to conform to the di-rect manipulation, and inserts it into the componenthierarchy using an appropriate command.

3.4.2 Manipulator Protocol

The manipulator protocol (Table 5) is designed to re-flect the grasp-wield-effect behavior of tools. TheGrasp operation takes a window system event (suchas a mouse click or key press) and initializes what-ever state is needed for the direct manipulation (suchas animation objects). During direct manipulation, theManipulating operation is called repeatedly until themanipulator decides that manipulation has terminated(based on its own termination criteria) and indicatesthis by returning a false value. The Effect operationgives the manipulator a chance to perform any finalactions following the manipulation.

Some kinds of direct manipulation may require sev-eral sub-manipulations to progress simultaneously (forinstance, the editor may aIlow the user to manipulatemore than one component at a time). A manipula-tor can therefore have children, and the manipulatorprotocol includes operations for iterating through andmanipulating them.

This simple protocol is sufficient to describe directmanipulations ranging from text entry and rubberband-ing effects to simulating real-world dynamics such asimparting momentum to an object. Unidraw imple-mentations can predefine manipulators for the mostcommon kinds of manipulation. Since manipulatorsmust maintain information that characterizes the finaloutcome of a manipulation, subclasses usually aug-ment the protocol with operations for retrieving statethat determines this outcome. For example, a manip-ulator that supports dragging the mouse to translate agraphical component will define an operation for re-trieving the distance moved.

Figure 5: Communication between objects during di-rect manipulation

3.4.3 Object Communication duringDirect Manipulation

Figure 5 diagrams the communication between objectsduring direct manipulation. The numeric labels in thediagram correspond to the transmission sequence:

1. The viewer receives an input event, such as thepress of a mouse button.

2. The viewer asks the current tool to CreateManip-ulator based on the event.

3. Manipulator creation: the tool either

(a) creates a manipulator itself (based on theselection or other information), or

(b) asks the component view(s) to create themanipulator(s) on its behalf. The tool mustcombine multiple manipulators into a com-posite manipulator. Each class of compo-nent view is responsible for creating an appropriate manipulator for the tool.

4. Direct manipulation: the viewer

(a) invokes Grasp on the manipulator, supplyingthe initiating event;

(b) loops, reading subsequent events and send-ing them to the manipulator in a Manipu-lating operation (looping continues until theManipulating operation returns false);

(c) invokes Effect on the manipulator, supply-ing the event that terminated the loop.

9 -

5. The viewer asks the current tool to InterpretMa-nipulator.

6. Manipulator interpretation: the tool either

(a) interprets the manipulator itself, creating theappropriate command, or

(b) asks the component view(s) to interpret themanipulator(s) on its behalf. The view(s)then create(s) the appropriate command(s).The tool must combine multiple commandsinto a composite (macro) command.

7. The viewer executes the command.

8. The command carries out the intention of the di-rect manipulation.

To illustrate this process, consider the followingexample of direct manipulation in a drawing editor.Suppose the user clicks on an rectangle componentview (Recfangle View) in the drawing area (viewer)with the MoveTml. The viewer receives a “mouse-button-wentdown” event and asks the current tool (theMoveTool, as provided by the enclosing editor) to Cre-ateManipulator based on the event. MoveTool’s Cre-ateManipulator operation determines from the eventwhich component view was hit and adds it to the se-lection. More precisely, the selection object providedby the enclosing editor appends the view to its list.

If the selection object contains only one componentview, then MoveTool’s CreateManipulator operationcalls CreateManipulator on that component view. Thisgives the component view a chance to create the ma-nipulator it deems appropriate for the MoveTool underthe circumstances. Since the user clicked on a Rectan-gleView, the component view will create a DragManipulator, a manipulator that implements an downclick-drag-upclick style of manipulation. DragManipulatorsanimate the dragging portion of the manipulation bydrawing a particular shape in slightly different ways ineach successive call to their Manipulating operation.The definition of DragManipulator parameter&es theshape so that subclasses of DragManipulator are notneeded to support dragging different shapes.

Once the viewer obtains the DragManipulator fromthe MoveTool, the viewer creates the illusion that theuser is “grasping” and “wielding” the tool. First theviewer calls Grasp on the manipulator, which allowsthe manipulator to initialize itself and perhaps drawthe first “frame” of the animation. Then the viewerloops, forwarding all subsequent events to the manip-ulator’s Manipulating operation until it returns false.Successive calls to Manipulating produce successive

- lo-

frames of the animation. Once manipulation is com-plete, the viewer invokes the manipulator’s Effect op-eration, which gives the DragManipulator a chance tofinalize the animation and the state it maintains to char-acterize the manipulation. The viewer then asks thetool to InterpretManipulator in this case, the Move-Tool in turn asks the RectangleView to InterpretMa-nipulator. In response, RectangleView constructs andreturns a MoveCommand, which specifies a transla-tion transformation. The RectangleView initializes theamount of translation in the MoveCommand to thedistance between the initial and final frames of the an-imation, which it obtains from the DragManipulator.

3.5 External Representations

An external representation of a component is simplya non-graphical view of the corresponding componentsubject. Domain-specific external representations arederived from the external view subclass of componentview.

The external view protocol defines two operations,Emit and Definition, that generate a stream of bytesconstituting the external representation. Emit initiatesexternal representation generation, and Definition iscalled recursively by Emit. Emit normally calls theexternal view’s own Definition operation first. Thenif the external view contains subviews, Emit must in-voke the children’s Definition operations in the properorder to ensure a syntactically-correct external repre-sentation.

Emit is often used to generate “header” informa-tion that appears only once in the external represen-tation, while Definition produces component-specific,context-independent information. For example, adrawing editor might define a PostScnipt View exter-nal view subclass that defines Emit to generate globalprocedures and definitions. Component-specific sub-classes of PostScriptView then need only define Def-inition to externalize the state of their correspondingcomponent. Thus when Emit is invoked on an in-stance of any PostScriptView subclass, a stand-alonePostScript representation (known as “encapsulated”PostScript) will be generated. When the same instanceis buried in a larger PostScriptView, only its definitionwill be emitted

The architecture predefines preorder, inorder, andpostorder external views. These subclasses managesubviews and support one of three common traversalsof the external view hierarchy.

4 Prototype ImplementationOur Unidraw prototype is a library of C++ classescontaining about 20,000 lines of source. It runs ontop of Interviews and the X Window System. Theprototype uses Interviews’ object-oriented structuredgraphics [lo] to support graphical components and itspersistent object facility for implementing catalog se-mantics.

C++ is an attractive language for our purposes be-cause of its efficiency and true object-oriented se-mantics, but it does not allow sending arbitrary mes-sages to objects. Messages are sent via strongly-typed procedure calls, so a class must declare allacceptable messages at compile-time. Thus, compo-nent operations such as Interpret and Uninterpret can-not be implemented by accepting untyped messagesfrom commands. In lieu of this capability, compo-nents must query the command to determine its class,but C++ cannot provide this information at run-time.We solved this problem in our implementation by us-ing the ISA operation defined for InterViews persistentobjects, but ideally the language would provide eitherrun-time class resolution or untyped (or dynamically-typed) method lookup.

The remainder of this section discusses two sig-nificant aspects of the implementation followed by abrief description of the three domain-specific editorswe have implemented with the Unidraw prototype.

4.1 View ConsistencyA component view must reconcile its internal statewith its subject’s when Update is called. This is usu-ally trivial for leaf components, but components withchildren must be prepared to restructure themselves toconform to their subject’s structure. To accomplishthis, the view could assume that all its children areinconsistent with their subjects’ and just rebuild themfrom scratch based on the subject’s structure. Thisapproach is simple but potentially expensive. More-over, the subject’s structure usually stays the same orchanges only slightly, so an incremental approach inwhich the view reuses most of its children is prefer-able. Our implementation supports the common casewhere the view’s child structure is identical to the sub-ject’s, Components with differing subject and viewstructures must implement their own update algorithm.

Figure 6 shows the algorithm. On Update, any chil-dren that no longer have a subject are destroyed. Thenthe list of child views is compared to the list of childsubjects. If there is a subject-view mismatch, the Up-dateCurrent operation is called. UpdateCurrent per-

- ll-

void UpdateViewStructure () {i&-&r subj = SubjectsFirstChild();Aerator view = ViewsFirstChild();

DeleteSubjectlessViews();

do {if (*subj != *view) {

UpdateCurrent(subj, view);

1AdvanceJsubj);Advance(view);

} until (Done(subj) 11 Done(view));UpdateExcessSubjects(subj);DeleteExcessViews(view);

1

Figure 6: View structure update algorithm

forms two searches through the remaining views andsubjects. If it does not find a view corresponding tothe current subject, it creates one and inserts it beforethe current view; otherwise, it moves the correspond-ing view to its proper position. If it does not find thecurrent view’s subject among the remaining subjects, itdeletes the view; otherwise, if the corresponding sub-ject does not follow the current subject, it moves theview to the end of the list of child views for repo-sitioning in subsequent iterations. The main iterationloop continues until either the subject or the view runsout of children. Finally, views are created for anyremaining subjects, and unused views are destroyed

4.2 Connector ImplementationConnectivity semantics are enforced by a csolver ob-ject that manages connection networks, or disjoint setsof connections. A connection consists of two connec-tors and a piece of connector glue. Connector glueis characterized by a natural size, elasticity, and de-formation limits. Elasticity is specified in terms of in-dependent shrinkability and stretchability parameters.Deformation limits are expressed as independent lim-its on the total amount the glue can stretch and shrink.A connection uses connector glue to define the re-lationship between connectors’ centers, thus definingtheir connectivity semantics. For example, connectorglue of zero natural size and elasticity is used to imple-ment pin-pin connection semantics. Pin-pad semanticsare modeled with a piece of glue of infinite elasticitywithin limits that keep the pin inside the pad.

Figure 7: Recursive solution of connection network

The csolver is responsible for solving constraint net-works that have been perturbed, meaning it must posi-tion the connectors to satisfy all connection semantics.The csolver stores each connection network as a listof connections. It solves each network by recursivelyidentifying primitive combinations of connections andreplacing them with equivalent connections. The twomost common primitive combinations are series andparallel connections. Figure 7 depicts the process ofrecursive substitution on a network having three con-nections. Connectors are shown as circles, and con-nector glue is represented by resistor symbols. Theshaded connectors have fixed mobility, while the oth-ers are floating. On the initial recursion, the csolveridentifies the parallel combination of G2 and G3 andreplaces it with an equivalent connection. It replacesthe resulting series combination with another equiv-alent connection on the second recursion, leaving asingle connection. Recursion terminates whenever asingle connection remains or all connectors are fixed,at which point the connectors’ positions are determi-nate. The csolver then unwinds the recursion, appor-tioning the amount of stretch or shrink applied to eachequivalent connection to the connections they replaceduntil the original network is obtained. Then the csolverissues move commands to the affected connectors.

4.3 Three Domain-Specific EditorPrototypes

We have built three domain-specific editors with ourprototype Unidraw library: a schematic capture system(see Figure 8), a user interface builder (Figure 9), anda drawing editor (Figure 10). All provide a direct-manipulation, multi-view editing environment. Theschematic capture system lets the user wire-up circuitelements (such as gates, latches, and pass transistors)

- 12-

and generates a netlist of the resulting circuit. Thesystem supports hierarchical composition of circuit el-ements and maintains graphical connectivity betweenthem. The user interface builder lets the user composea user interface in terms of Interviews toolkit abstrac-tions and generates C++ source code to be incorporatedinto the target application. Finally, the drawing editorprovides MacDraw-like functionality (with the addedbenefits of multiple views) and generates PostScript.The prototype schematic capture system and user in-terface builder are less than 5000 lines each, while thedrawing editor is less than 2500 lines.

5 Conclusion

Figure 8: Schematic capture system prototype

Figure 9: User interface builder prototype

Unidraw greatly facilitated the implementation of ourthree prototype domain-specific editors. Though theseeditors do not yet represent production-quality sys-tems, they have proven to be useful tools for their in-tended purposes. Unidraw narrowed the design spacefor each editor significantly, obviating basic design de-cisions that are independent of the domain. The proto-type library provided reusable functionality in the formof predefined components, commands, and tools. De-bugging time was reduced because much less code waswritten. Our experience is that developing domain-specific editors with Unidraw is mainly a matter ofchoosing, designing, and implementing the requireddomain-specific components. Significantly less effortis spent defining new commands, while specializedtools are needed the least often.

The architecture is undergoing continuous refine-ment as we experiment with the prototype. Fertileground for future research involves additional supportfor external representations, which is a difficult prob-lem in general. We would like to go beyond the currentpredefined external view traversals to develop a morepowerful model that includes support for interpretingexternal representations. This capability would let adomain-specific editor read in existing representations,including those not generated by the editor itself. Forexample, a schematic editor could read in an existingnetlist, allow the user to edit it graphically, and gen-erate a new netlist. A logic simulator could then givethe user feedback about the modified circuit’s behav-ior, which might prompt him to edit the circuit again.The ability to read as well as write external repre-sentations permits iterative design by closing the loopbetween specification and analysis, making Unidraw-based tools even more useful.

Figure 10: Drawing editor prototype

- 13 -

References[l] LabVIEW Manual. National Instruments Corp.,

1987.

[2] P.S. Barth. An object-oriented approach to graph-ical interfaces. ACM Transactions on Graphics,5(2): 142-172, April 1986.

[3] Alan H. Boming. ThingLub - A Constraint-Oriented Simulation Laboratory. Technical Re-port SSL-79-3, Xerox Palo Alto Research Center,July 1979.

[4] Steven H. Gutfreund. ManiplIcons in Thinker-Toy. In ACM OOPSLA ‘87 Conference Proceed-ings, pages 307-317, Orlando, FL, October 1987.

[5] R.J.K. Jacob. A state transition diagram languagefor visual programming. Computer, 18(8):51-59,August 1985.

[6] Mark A. Linton, John M. Vlissides, and Paul R.Calder. Composing user interfaces with Inter-Views. Computer, 22(2):8-22, February 1989.

[7] M.K. Molloy. A CAD tool for stochastic petrinets. In Proceedings of the 1986 Fall Joint Com-puter Conference, pages 1082-1091, Dallas, TX,November 1986.

[8] Nan C. Shu. Visual Programming. Van NostrandReinhold, New York, 1988.

[9] I.E. Sutherland. Sketchpad: A Man-MachineGraphical Communication System. PhD thesis,MIT, 1963.

[lo] John M. Vlissides and Mark A. Linton. Applyingobject-oriented design to structured graphics. InProceedings of the 1988 USENK C+ + Confer-ence, pages 81-94, October 1988.