The following paper was originally published in the Proceedings of the Sixth Annual Tcl/Tk 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
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 c «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.