The following paper was originally published in the Proceedings of the Sixth Annual Tcl/ Workshop San Diego, California, September 14–18, 1998

The Tycho Slate: Complex Drawing and Editing in Tcl/Tk

H. John Reekie and Edward A. Lee University of California, Berkeley

For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org/

The Tycho Slate: Complex Drawing and Editing in Tcl/Tk

H. John Reekie and Edward A. Lee

School of Electrical Engineering and Computer Sciences

University of California { Berkeley

Berkeley CA 94720

fjohnr,[email protected]

let

Abstract

This paper introduces the Slate package, which has

been developedaspart of the Tycho project at UC

Berkeley. The Slate is layered over the Tcl/Tk can-

vas, and contains features that we believe to be useful

for implementing complex graphical editing and vi-

Figure 1: A fragment of a visual program

sualization widgets. The rst key feature is the abil-

ity to de ne new item types in Tcl. The second is an

We decided very early on that our implementation

implementation of the concept of interactor, which

would b e only in [incr Tcl], in order to guarantee

abstracts low-level mouse events into self-contained

p ortability. More recently,we used the namespace

objects. The thirdisaccess to and modi cation of

facility of Tcl 8.0 to p ort the co de to Tcl 8.0, and it

items based on their shape, rather than raw coordi-

now runs in either Tcl and [incr Tcl]. Although the

nates. Combined with a straight-forward implemen-

Tcl-only decision presented its own set of implemen-

tation of the model-view-control ler architecture, the

tation challenges, wewere able to achieve acceptable

Slate is capable of implementing quite sophisticated

p erformance and the p ortabilitywe desired. The

graphical editors.

Slate should, in fact, work with any canvas exten-

sion, since it uses only the standard canvas interface

provided by Tcl/Tk.

1 Intro duction

After some exp erimentation, we ended up with a

package that implements the following:

The Tk canvas provides a simple but p owerful

set of structured graphics primitives, and is p erhaps

User-de ned items The key feature that makes

the easiest to olkit available for drawing simple 2D

the Slate useful is the ability to de ne new item

graphics. When we started to use the Tk canvas

typ es in Tcl. Items can b e comp osed recur-

with a view towards implementing various graphi-

sively, pro ducing a straight-forward visual hier-

cal diagram editors, however, we realized that we

archy, as is common in many graphics packages

needed a more p owerful layer of abstraction.

see, for example, [2]. All of the canvas meth-

To illustrate, gure 1 shows a mo ck-up visual pro-

o ds are rewritten to handle hierarchical items.

gram of the kind that wewere interested in im-

plementing. This is a sample of a language devel-

Item shap es Every item has a shap e, suchas

op ed in [10]. The rectangle marked \let" encloses

point, rectangle, polygon, or a custom-designed

an expression, and the value of the expression is

shap e. Items can b e queried for the co ordinates

indicated by the arrow connecting the two trian-

of a feature, such as the north-east corner or the

gular \terminals." The let-expression itself is con-

second vertex. Items can b e requested to move

nected to another function b ox. Items within the

one or more features, reshaping the item.

let-expression can b e moved only within that frame,

while moving the whole frame will moveeverything Interactors Event-handlers can b e b ound to any

contained within it. This combination of hierarchy level of the visual hierarchy. In addition, we

and complex user interaction necessitated a higher- implemented a more abstract and more p ow-

level framework than the raw canvas. erful user interaction framework, in which par- Shape

Rectangle Oval Line Interactor Point Polygon

bind unbind Item Slate Canvas tags coords children bind addtag create feature delete move find reshape

ComplexItem SimpleItem parent

{children /= { }} {children = { }}

Figure 2: The key framework classes

2.1 Complex item classes ticular sequences of user interaction events are

abstracted into ob jects called interactors.

To add a new item typ e to the slate, the pro-

We also added other useful metho ds, such as high-

grammer sub classes the ComplexItem class. Once

lighting and selection. Unlike many research to olk-

de ned, items of the new typ e can b e created and

its, we did not implement a constraint system, for

manipulated just like regular Tk canvas items. For

reasons detailed in a later section.

example, one of the item typ es that we supply with

the Slate is called Frame , b ecause it mimics the ap-

p earance of the Tk frame widget. To create a new

2 The core graphics framework

frame on a slate, we can execute co de such as this:

set frame [$slate create Frame \

The Slate is implemented as a set of classes, or-

50 50 100 100 \

ganized around one key class called Slate .Wehave

-color green -relief ridge]

tried to make the Slate a plug-in replacement for

the Tk canvas. A simple example:

which pro duces the item shown at the top left of

set slate [::tycho::slate .s \ gure 3. This item b ehaves likeany other Tk canvas

-height 300 -width 400 \ item { for example, we can change its co ordinates:

-background white]

$slate coords $frame 70 70 140 120

pack $slate -fill both -expand 1

We can move it:

Figure 2 shows a conceptual representation, in the

Ob ject Mo deling Notation [11], of the key classes.

$slate move $frame 40 20

The diagram is conceptual only, b ecause manyof

these classes do not in fact exist { in the implemen-

We can get a list of items overlapping a given region

tation, they are faked using Tcl pro cedures, canvas

of the canvas, which will in this case include this

item tags, and asso ciative arrays.

item:

The Slate class is wrapp ed around a Tk canvas.

It contains an arbitrary number of Item s, which are

set found [$slate find \

graphical elements that app ear on the screen. An

overlapping 100 100 200 200]

Item is either a ComplexItem , which is in turn an

aggregation of Items, or a SimpleItem , which rep- Figure 3 shows several other complex item typ es.

resents a single Tk canvas item such as a line or At the top rightisaSolid , which is a p olygon with

rectangle. Each item has a Shape see section 2.3, a pseudo-3D b order like Frame ; at the b ottom left

and can b e op erated on by an arbitrary number of is a LabeledRectangle, which is a rectangle with a

Interactor s see section 3.2. lab el and arbitrary graphics nested within it in this

Figure 4: A dynamically-constructed complex item

Figure 3: Some pre-de ned complex items

will return f50 50 100 100g. The co de

$slate scale $citem 50 50 0.5 1.5

case, two lines; at the b ottom rightisaSmartLine,

which is a line that, given two end-p oints and the

will scale the item, pro ducing the item at the center

directions at those ends n, s, e,orw, draws itself

of gure 4.

as one or more orthogonal segments. We emphasize

In general, arbitrarily complex items can b e built

that these items are a sample of those that we found

up this way. Figure 5 shows one such hierarchy, sim-

useful for building graphical editors, and that it is

ilar to those we use in one of our graphical editors.

quite simple to create new item typ es or to extend

As a general rule, a programmer should de ne a new

existing typ es by sub classing.

sub class of ComplexItem when a particular graphi-

2.2 Constructing hierarchy

cal representation is used again and again, and use

dynamic comp osition of items, such as just given,

Any sub class of ComplexItem can add items to it-

when items are combined as part of the editing op-

self, thus creating a recursive hierarchy of items. For

erations in a graphical editor.

example, a Frame item consists of four simple items:

a rectangle for the central surface, two p olygons for

2.3 Shap e

the \lit" and \shaded" b orders, and a transparent

rectangle that is used as a place-holder for the co-

Each item on a slate has a shape. Shap es provide

ordinates of the whole Frame .

more sophisticated control over the co ordinates of

In addition to creating hierarchyby creating new

an item than just its raw co ordinates. Simple items

item typ es, an instance of the ComplexItem class

have a shap e that cannot b e changed; complex items

can have arbitrary sub-items added to it. To illus-

have a shap e that is determined by the class de ning

trate, we can create a blank complex item:

that item. Prede ned shap es mimic the primitive

canvas item typ es: point, rectangle, oval, line , and

set citem [$slate create ComplexItem \

polygon.

50 50 100 100]

An item with a given shap e has a set of attributes

called features.Features are inspired by Gleicher's

The co ordinates give the region to b e o ccupied by

work on constraint-based graphics [3]. A feature is

the item so that metho ds suchascoords will op erate

typically a p oint lo cation on the item. An item can

correctly.Nowwe can add items to it. For the sake

b e queried to nd the value of a feature, and the

of example, let's add a pair of lines and an oval to

feature can b e moved to change the shap e of the

it:

item. For rectangular items, the default features

$slate createchild $citem line \

are its center, the four corners, and the four edges;

50 50 100 100

for lines, the features are the vertices of the line.

$slate createchild $citem line \

For example, to nd the co ordinates of the north-

50 100 100 50

west corner of a rectangular item, we could execute:

$slate createchild $citem oval \

60 60 90 90 -fill green

set northwest [$slate feature $frame nw]

The item that results is shown at the left of gure 4.

To reshap e the item bymoving the north-west cor-

Likeany slate item, this item resp onds to metho ds

ner left and down ten pixels, we could execute:

that move and scale it. For example,

$slate coords $citem $slate reshape $frame -10 10 nw MapIcon map parent

Label map MapGlyph Terminal parent children

Frame Frame

Figure 5: A sample visual hierarchy

All features can b e read, but not all can b e set; 3 Interaction mechanisms

center, for example, can b e read but not set. Any

feature that can b e set can also b e grappled { that

The visual hierarchy provides an elegant means of

is, have a grab handle attached to it. For example,

constructing drawings, but do es not by itself provide

executing the co de:

user interaction. To e ectively supp ort construction

of visual language editors, we need to provide ways

$slate grapple $citem

of adding user interaction.

will add grab handles to the four corners and edges

3.1 Bindings

of the given item. The e ect of executing this co de

is shown on the right of gure 4 { this item can b e

The rst interaction mechanism supp orted by the

resized by dragging any of the grab handles.

slate directly mimics the binding mechanism of the

The Shape classes are implemented as collections

Tk canvas. With this mechanism, a command can

of class pro cedures { each class handles feature

b e b ound to an event and an item. For example,

queries and reshaping of all items with that shap e.

executing

Complex items can cho ose their own set of features

byoverriding their shap e-related metho ds. For ex-

$slate bind $citem {puts !!}

ample, the Terminal item in gure 5 has features

called \origin" and \terminal," which are its base

will add a binding to citem. Whenever the mouse is

and connection p oint resp ectively.

clicked on item citem, the string \!!" is printed to

the console.

2.4 Tags

In the presence of a visual hierarchy, bindings take

on some subtle complications. In gure 5, for ex-

ample, I want a click on either frame to b e handled

Tagging in the Slate is a fairly straight-forward

by the top-level item. Dragging these items should

extension of the way that tags are implemented on

move the whole tree of items. The terminal item,

the Tk canvas. Any item can b e tagged. For exam-

however, should resp ond di erently { in this case, I

ple, given some item citem ,we can write

want clicking and dragging on the terminal item to

$slate addtag "fred" withtag $citem

create a new arrowed line and extend the end of the

line to follow the cursor. Also, dragging on the text

Some time later, we could write

lab el will sometimes need to select a region of the

text.

$slate move "fred" -10 0

Our solution is to mark no des of the tree: only

whichwould move citem, including all of its comp o- marked no des are able to resp ond to user input.

nents, ten pixels to the left. Any other item tagged Figure 6 illustrates a marked tree, in which no des

with \fred" will also b e moved. Anynodeinthe a and e are marked. With resp ect to any no de, its

hierarchy can b e tagged in this way, and p erforming root node is the ro ot of the lowest marked sub-tree

an op eration on the tag will op erate on the corre- containing it. The top-level no de is the ro ot of the

sp onding subtree of the hierarchy. whole tree, and is implicitly marked. Conceptually, Click handler «Click» Drag interactor «Click» «Drag» «Drag» Drag handler «Drag» a «Release» Move commands «Drag» a Edit interactor b «Key-H» b c «Key-w» Key handler «Delete» «Key» «Key-e» d e d e Edit commands

f g f g

Figure 6: Events and interactors in the visual hierarchy

3.2 Interactors when an event o ccurs on an item, the event is prop-

agated up the tree until it reaches a marked no de, at

The second interaction mechanism is based on in-

which p oint the event is handled. This is illustrated

teractors, prop osed byMyers in 1990 [7] and im-

at the left of gure 6: no de a will handle events

plemented in the Garnet to olkit and its successor,

from itself, b, c, and d;nodeewill handle events

Amulet [8,9]. Interactors abstract user interac-

from itself, f , and g .

tion from the lower-level events up on which they

In the current implementation of the Slate, no des

are built, and in the pro cess mo dularize the co de

can only b e marked when they are created. Return-

and make it more re-usable.

ing to our earlier example, we can create a child

An interactor is an ob ject that intercepts events

item of a ComplexItem that resp onds to user input

and translates them into op erations on a target item.

with co de such as this:

For example, a Fol lower interactor { so called b e-

cause it \follows" the mouse { translates mouse

set flag [$slate createrootchild \

events into calls to the moveclick, movedrag, and

$citem rectangle \

moverelease metho ds of the slate. To create a Fol-

40 50 50 60 -fill red]

lower interactor, we can execute, say:

$slate bind $flag \

{puts Foo}

set follower \

[$slate interactor Follower]

Events can also b e used with tags. For example, we

To makeaninteractor op erate on an item, we bind

can write

the interactor to that item. For example,

$slate bind "fred" \

$follower bind $frame -button 1

{puts "Clicked fred!"}

Now, dragging the frame item with the mouse makes

it move { simple! To stop the item from resp onding

and any top-level or marked child item tagged with

to the mouse, unbind the interactor:

fred { that is, it and the no des for which it handles

events { will resp ond to the event.

$follower unbind $frame -button 1

If used without any hierarchy, the slate thus pro-

The right side of gure 6 illustrates twointeractors vides the same mechanism as the canvas for event-

b ound to no des of a hierarchy.Interactors can b e handling. The visual hierarchy aids more complex

cascaded to create more complex interaction. For item construction without discarding this p owerful

example, an interactor that moves an ob ject only mechanism. However, the binding mechanism is

within a certain region of the slate can b e cascaded low-level, and complex user interaction built on this

with an interactor that quantizes movement to ten- mechanism very quickly mushro oms into spaghetti-

pixel steps. like co de. cascade

bound Item Interactor button activated moveclick modifiers movedrag callbacks moverelease bind unbind click delegate drag release mode

Selector Follower Repeater

Stepper Bounder DragDropper

Figure 7: The interactor classes

A more complex combination is achieved with the pace when necessary { for example, a command such

Selector interactor, which manages a graphical se- as

lection in the same manner as typical drawing pro-

$slate create Frame 40 40 80 80

grams. When items b ecome selected, the Selector

delegates interaction events to another interactor ac-

will call the construct pro cedure in the Frame

cording to various conditions that can b e set up

namespace. To simulate inheritance, each names-

by the programmer. For example, it might forward

pace contains an asso ciative array mapping metho d

mouse and keyb oard events to a LineEditor inter-

names to the appropriate pro cedure, whichisover-

actor if there is only a single text item selected,

written in each \sub-class."

and forward mouse events to a Fol lower interactor

We used some other tricks as well. For example,

if more than one item is selected.

to access option variables and instance variables, we

Interactors allow user interaction co de to b e mo d-

index a shared arrayby a combination of a name and

ularized, and, just as imp ortantly, reused. In ad-

the ID of the item. This allows the Slate uniform

dition, they allow highly dynamic user interaction,

access to the internals of complex items, regardless

suchaschanging the e ect of the mouse dep end-

of class. For example, a pro cedure in Frame that

ing on the context such as the numb er of items se-

accesses its color option would use:

lected. This kind of dynamic mo di cation of user

interaction would b e very dicult if co ded directly

set foo $optioncolor$id

using event bindings. Some additional examples of

We use tags to simulate hierarchical complex

interactors are given in section 5.

items. Although this seems conceptually simple, ac-

tually doing it in the presence of event bindings is a

little tricky. Each complex item is assigned a unique

4 Implementation notes

ID when it is created { we use an integer preceded by

an underscore the Tk canvas uses plain integers.

As mentioned previously, the ComplexItem

Every simple item within a complex item is tagged

\class" and its sub classes, which de ne new item

with that ID:

typ es, are not really implemented using classes. Be-

cause the natural implementation of complex visual

Tagging rule 1: Every simple item

elements in Tk utilizes item tags to avoid recursive

within a complex item is tagged with that

tree-walks, we attened the ob ject structure as well.

item's ID.

In a language that supp orts ne-grained ob jects,

The corollary is that every simple item is tagged suchasJava, wewould use separate ob jects and

with the IDs of all items ab ove it in the hierarchy recursive tree-walk algorithms.

{ this makes moving a subtree easy.Now, user in- Each \class" is thus a collection of pro cedures

teraction often requires nding the ro ot item con- that accept a slate, the contained canvas, and an

taining a simple item. To make this ecient, each item ID as the rst three arguments. Metho ds of

simple item within a hierarchyisgiven a sp ecial tag: the slate call pro cedures in the appropriate names-

Tagging rule 2:Every simple item con-

tained in a complex item is tagged with the

ID of its ro ot pre xed by \!".

The corollary of this rule is that any simple item

that do es not have a tag starting with \!" is not in a

hierarchy. With these rules, it is easy conceptually

{ the implementation is a little tricky to nd, move,

and manipulate complex and simple items.

Now, some additional rules are needed to e ec-

Figure 8: A custom slider widget

tively deal with event bindings and, by extension,

interactors. Since a simple item can have only one

5.1 Custom widgets

ro ot, it can have at most one tag b eginning with

\!". Therefore, when binding an event to a complex

One of our rst uses of the Slate was to build a

item, we follow this rule:

custom slider widget, shown in gure 8. It lo oks

Binding rule 1:To bind an eventtoa

much b etter in real life when you have several lined

complex item, bind to the tag constructed

up together. This slider widget mimics the slid-

by pre xing its ID with \!".

ers used in audio control equipment in app earance,

but mimics the Tk scale widget in b ehavior. Four

The net e ect is exactly as it would b e if events

interactors are used to pro duce the desired user in-

were propagated up the hierarchyuntil a marked

teraction.

no de were found. Finally,events can also b e b ound

Figure 9 shows co de for a simpli ed version of this

to tags, which is the same as binding to a tag on the

widget. The four sections of this co de:

canvas:

1. Create the four items show in the diagram: two

Binding rule 2:To bind an eventto

text lab els and two pseudo-3D rectangles.

a tag, bind the event to that tag on the

canvas.

2. Create and bind a Bounder interactor, which

moves the slider bar up and down and keeps it

The implementation of most slate metho ds based

within the desired limits.

on these rules is reasonably straight-forward. Each

metho d tests for three typ es of argument { a simple

3. Create and cascade a Stepper interactor, which

item ID, a complex item ID, or a tag { and acts

quantizes movementtomultiples of 0.5 in this

accordingly.For example, a typical metho d has the

example.

pattern:

4. De ne a pro cedure that is called whenever the

if { [string match {[0-9]*} $tag] } {

bar is moved. The pro cedure calculates the

 Process a canvas item

value represented by the bar, and up dates the

...

numeric text item.

} elseif { [string match {_*} $tag] } {

 Process a complex item

In the real Slider widget, there are two other in-

...

teractors that i step the slider towards the mouse if

} else {

the left button is clicked on the background, and ii

 It's a tag: find matching items

cause the bar to jump to the p osition of a button-2

set items [find withtag $tag]

click and then follow the cursor.

...

All told, constructing this widget was relatively

}

easy, and we didn't have to write a single event bind-

ing.

5 Building useful to ols

5.2 Graphical editors

The Slate itself is only part of the infrastructure

needed to build useful to ols. In this section we Figure 10 shows a snapshot of one of the graph-

brie y describ e our implementation of some to ols ical editors constructed using the Slate. This edi-

that use the Slate. tor is the front-end for Ptolemy I I, a new version

 Create the display elements

set value [$slate create text 50 20 -text 0 -anchor s -fill blue]

set trough [$slate create Frame 48 23 52 143 -color darkgrey \

-borderwidth 2 -relief sunken]

set bar [$slate create Frame 40 132 60 142 \

-color darkseagreen -borderwidth 3]

set label [$slate create text 50 150 -text "Fred" \

-anchor n -justify center]

 The bounder moves the bar along the trough

set bounder [$slate interactor Bounder \

-dragcommand "updateWidget $slate $bar $value" \

-constrain y -bounds {0 24 0 142}]

$bounder bind $bar -button 1

 The stepper quantizes movement to increments of 0.5

set stepper [$slate interactor Stepper -stepsize [expr 108.0/22]]

$bounder cascade $stepper

proc updateWidget {slate bar value args} {

set position [expr [lindex [$slate coords $bar] 1] + 5]

set x [expr 137.0-$position/108.0 * 10.0]

$slate itemconfigure $value -text [format .1f $x]

}

Figure 9: A simple example of a custom widget

of Ptolemy[6] b eing written in Java. The par- terminals, the interactors forward events to either

ticular system shown is a second-order continuous- an edge controller or a vertex controller. The ar-

time simulation, written by Jie Liu of UC Berkeley. chitecture is shown in gure 11. The controller rst

In this editor, icons can b e selected from a library decides what the user interaction means in terms

stored as ASCI I text, which describ es each icon in of the underlying semantics of the visual program,

terms of the ComplexItem typ e used to draw it, the and mo di es the semantic model accordingly in this

numb er and lo cation of terminals, the lab el, and the example, the semantic mo del is a directed graph.

graphics to draw up on the surface of the icon. The controller also decides what visual asp ects of

the program havechanged, suchasmoving the end

Once placed, icons can b e selected and moved

of a line, or adding a new icon. It mo di es the

around. This is done using the Selector and Fol-

layout model accordingly, which in turn noti es the

lower interactors. When the mouse moves over an

view containing the slate, which in turn up dates to

unconnected terminal of an icon, a DragDropper in-

re ect the new app earance.

teractor is activated, which highlights the terminal

to indicate that it is \ready." If the mouse is clicked This seems, at rst, somewhat complicated, but

on the terminal, the DragDropp er creates a new our exp erience indicates that it do es leads to highly

SmartLine item, and reshap es the line so that the mo dular and customizable editors. We are, how-

end follows the cursor. When the end of the line ever, still gaining exp erience with this architecture.

moves over a terminal, the DragDropp er activates a Interactive resp onse is very go o d, partly b ecause

call-back to test if the terminal is a suitable \drop the interactor mo del is able to optimize incremen-

target." If it is, it snaps [4] the end of the line to the tal mouse movements while items are b eing dragged

connection p oint of the terminal, altering the shap e ab out on the screen.

of the line to make it join at the exp ected angle.

Finally,we note here our observations on the use

Internally, this graphical editor uses a variantof of constraints, as included in many exp erimental

the mo del-view-controller architecture see, for ex- to olkits [8, 9], for example. In constraint systems,

ample, [1]. As the user places icons and connects the programmer sets up constraints b etween graph-

Figure 10: A snapshot of a graphical editor

over the Tk canvas. Because it is written entirely in ical items, which the constraint system attempts to

Tcl/[incr Tcl], it is highly p ortable and should work maintain as conditions change. For example, our

with any other canvas extension. editor could have constraints set up such that the

ends of attached lines move when an icon is moved.

The Slate is part of the Tycho user interface sys-

tem [5], which can b e obtained from the Tycho home

We wrote a simple constraint system early on,

page:

and found that writing constraints to catch the right

conditions and to avoid cycles was tricky.We ended

http://ptolemy.eecs.berkeley.edu/tycho/

up trashing the constraint system { simple though

it was { when we realized that the mo del-view-

Current developmentversions of the Slate can b e

controller architecture o ers a b etter and simpler

obtained from:

alternative. If you lo ok at gure 11, you can see

that, as an icon is moved, the layout mo del must b e

http://ptolemy.eecs.berkeley.edu/

mo di ed for attached edges as well as the icon. How

~johnr/code/slate

do we know what edges to move? Why,by lo oking

at the semantic mo del!

Acknowledgments

Thus, we concluded that, in interfaces that have

an underlying semantic mo del, using that mo del

Key infrastructure without which this pro ject

with an appropriate controller ob ject is a more

would not have b een p ossible has b een develop ed

straight-forward solution than general-purp ose con-

by: Michael McLennan of Bell Labs [incr Tcl]/[incr

straint solvers. In addition, since wehave a compre-

Tk], John Ousterhout of Scriptics Corp oration

hensive set of interactors, it is also straight-forward

Tcl/Tk, and Mark L. Ulferts of DSC Communi-

to implement purely-syntactic constraints by appro-

cations Corp [incr Widgets]. We also thank the

priately con guring interactors. For example, keep-

reviewers for their careful reading and comments on

ing the slider in gure 8 on the right track do es not

this pap er.

require constraints, just the rightinteractor.

Tycho is part of the Ptolemy pro ject, which

is supp orted by the Defense Advanced Research

Pro jects Agency DARPA, the State of California

6 Concluding remarks

MICRO program, and the following companies: The

Alta Group of Cadence Design Systems, Hewlett

The Slate is, we feel, a p owerful and useful to ol Packard, Hitachi, Hughes Space and Communica-

that provides a signi cant increase in abstraction tions, NEC, Philips, and Ro ckwell. Interactors I Edge controller View I I

Vertex controller

Layout model

Semantic model

Figure 11: The architecture of a graphical editor

References [9] Brad A. Myers, Richard G. McDaniel,

Rob ert C. Miller, Alan S. Ferrency, Andrew

[1] Dave Collins. Designing Object-Oriented User

Faulring, Bruce D. Kyle, Andrew Mickish, Alex

Interfaces. Benjamin/Cummings, 1995.

Klimovitski, and Patrick Doan. The Amulet

environment: New mo dels for e ective user in-

[2] James D. Foley, Andries van Dam, Steven K.

terface software development. IEEE Transac-

Feiner, and John F. Hughes. Computer Graph-

tions on Software Engineering, 236:347{365,

ics: Principles and Practice. Addison-Wedley,

June 1997.

1996. Second Edition.

[10] H. John Reekie. Realtime Signal Process-

[3] Michael Gleicher. A Di erential Approach to

ing: Data ow, Visual, and Functional Pro-

Graphical Manipulation. PhD thesis, Carnegie

gramming. PhD thesis, Scho ol of Electrical

Mellon University, 1994. Also app ears as CMU

Engineering, UniversityofTechnology, Sydney,

Scho ol of Computer Science Technical Rep ort

Australia, Septemb er 1995.

CMU-CS-94-217.

[11] James Rumbaugh, Michael Blaha, William

[4] Scott E. Hudson. Semantic snapping: A tech-

Premerlani, Frederick Eddy, and William

nique for semantic feedback at the lexical level.

Lorenson. Object-OrientedModeling and De-

In Proc 1990 SIGCHI Conference, pages 65{70,

sign. Prentice-Hall, 1991.

April 1990.

[5] Christopher Hylands, Edward A. Lee, and

H. John Reekie. The Tycho user interface sys-

tem. In The 5th Annual Tcl/Tk Workshop '97,

pages 149{157, 1997.

[6] Edward A. Lee and David G. Messerschmitt

et al. An overview of the Ptolemy pro ject.

http://ptolemy.eecs.berkeley.edu/papers/

overview/, March 1994.

[7] Brad. A Myers. A new mo del for handling in-

put. ACM Transactions on Information Sys-

tems, 83:289{320, July 1990.

[8] Brad A. Myers, Dario Giuse, Roger B. Dan-

nenb erg, Brad Vander Zanden, David Kos-

bie, Ed Pervin, Andrew Mickish, and Philipp e

Marchal. Garnet: Comprehensive supp ort

for graphical, highly-interactive user interfaces.

IEEE Computer, 231, Novemb er 1990.