Spreadsheet programming permits much of a graphical interface to be specified declaratively using equations and then automatically implemented via a constraint solver. For example, to specify that a rectangle should be positioned 10 pixels to the right of another rectangle, and flush with the top of this rectangle, the programmer might create the constraints:

rect2.left = rect1.right + 10 rect2.top = rect1.top

Whenever *rect1* moves, *rect2* will automatically move as
well.

The equations that may be specified are much like the equations that may be specified in a spreadsheet. An equation defines the value of a variable (called a cell in a spreadsheet), and may depend on one or more variables (cells) for input. When the value of a variable (cell) is modified, a scheduling algorithm ensures that all equations which depend on this changed variable are reevaluated in the appropriate topological order.

Spreadsheet-style equations are rapidly gaining popularity in interactive applications because they:

- simplify the programming task;
- express relationships over multiple data types, including numbers, strings, booleans, bitmaps, fonts, and colors;
- can be solved quickly enough to provide a user of an interactive application with immediate feedback;
- are conceptually simple.

The generality of spreadsheet-style constraints allows them to specify a rich variety of the graphical relationships and behaviors that are found in interactive applications. Programmers use them to 1) specify the graphical layout of objects, 2) maintain consistency between the application data and the graphical objects used to display this data, 3) maintain consistency among multiple views of data, 4) specify how graphical objects should respond to input events, and 5) hierarchically compose complex objects from simpler objects.

Because of their utility, spreadsheet-style constraints are now used in a wide variety of interactive applications, including graphical interface toolkits, graphical layout systems, simulation systems, animation systems, imperative programming languages, and programming environments.

Our research has been aimed at adding features to spreadsheet-style equations that make them capable of expressing a greater variety of graphical relationships. The features our research has explored includes

- pointer variables: Pointer variables allow an equation to reference
objects indirectly through pointer variables. For example, if we wanted
to be able to position
*rect2*to the right of an arbitrary object, we could have specified the above constraints as:rect2.left = obj_next_to->right + 10 rect2.top = obj_next_to->top

where*obj_next_to*is a pointer variable that points to the object that*rect2*should appear to the right of. - multi-output equations: Multi-output equations allow an equation to
output to more than one variable. The programmer
frequently views several related computations as a single computation
(e.g., unpacking a data structure into multiple variables). Multi-output
constraints allow a programmer to express such a computation
naturally as the sum of its constituent parts.
For example, most programmers prefer using
a multi-output constraint to equate two points, rather than two
single-output constraints, as illustrated below:
**multi-output constraint**constraint: pt1 = pt2 methods: {pt1.x = pt2.x; pt1.y = pt2.y} {pt2.x = pt1.x; pt2.y = pt1.y}**single-output constraints**constraint: pt1.x = pt2.x methods: {pt1.x = pt2.x} {pt2.x = pt1.x} constraint: pt1.y = pt2.y methods: {pt1.y = pt2.y} {pt2.y = pt1.y} - multi-way equations: Multi-way equations allow an equation to be
solved in multiple directions in order to satisfy the equation. For example,
the constraint
*rect2.left = rect1.right + 10*can be inverted so that*rect1.right*is solved for in terms of*rect2.left*. Multi-way constraints make it easier to maintain consistent views among multiple objects (e.g., if any one changes value, constraints ensure that all other objects are appropriately updated) and to specify that geometric relationships hold in both directions.

- Rick Halterman (Phd)

``An Active-Value-Spreadsheet Model
for Interactive Languages'', In * Languages for Developing User
Interfaces*, Brad Myers, ed., Jones and Bartlett Publishers, Boston,
MA, 183-210, 1992.

``Optimizing Toolkit-Generated Graphical
Interfaces'', *1994 ACM SIGGRAPH Symposium on User Interface Software
and Technology*, Marina del Rey, CA, November, 1994, pp. 157-166.

``Integrating Pointer Variables into One-Way
Constraint Models'', *ACM Transactions on Computer Human
Interaction*,
1, 2, (June 1994), 161-213.

``An Incremental Algorithm for Satisfying
Hierarchies of Multi-way, Dataflow Constraints'', *ACM Transactions on
Programming Languages and Systems*, 18(1), Jan. 1996, 30-72.

``Lessons Learned About One-Way, Dataflow Constraints in the Garnet and Amulet Graphical Toolkits'', in preparation.