The LiveWorld environment is made out of boxes or frames. The terms are used interchangeably except in contexts where there is a need to distinguish between the screen representation (box) and the internal structure (frame). From the user's perspective, they are the same. Boxes are named and can contain other boxes as annotations. Boxes thus form a hierarchical namespace, with a single distinguished box as the root. The inverse of the annotation relation is called home, so that all boxes except the root have exactly one home. Framer's syntax for referring to frames uses a syntax based on Unix pathnames. #/ designates the root frame, #/theater-1 designates an annotation of #/ named theater-1, and #/theater-1/cast/bug/xpos designates a frame named xpos several levels down in the hierarchy whose home is #/theater-1/cast/bug. LiveWorld introduces some variants on this syntax which are explained in section 4.5.4.2. Boxes also can have a value or ground, which may be any Lisp object, including another box. The value allows a box to serve as a slot.
A box can have a prototype, from which it inherits values and annotations. For example, the prototype of #/poodle is #/dog. #/poodle will inherit all the properties of #/dog, but can override ones in which it differs, such as #/poodle/hair-curliness. The inverse of the prototype relation is the spinoff, so #/dog has #/poodle as a spinoff. By default, a frame's prototype is the annotation of its home's prototype with the same name. For example, if the prototype of #/dog is #/wolf, then the default prototype of #/dog/personality will be #/wolf/personality. However, the prototype can be any frame at all, so that while #/rover might be a spinoff of #/dog, #/rover/personality could be changed to be a spinoff of #/sheep/personality. Within LiveWorld, new frames are usually created by cloning existing frames; see 4.4.4. Framer provides only single inheritance (a frame can have at most one prototype). But since contained frames can have their own prototypes that violate the default rule, it is possible to simulate some of the effects of multiple inheritance.
LiveWorld's display consists of a single hierarchy of nested boxes, each representing a frame. A typical set of boxes is illustrated in Figure 4.3.
Figure 4.3: Boxes and their parts. The labels denote parts or relations relative to the object my-turtle.
Boxes consist of the following graphic elements (from left to right on the top in Figure 4.3): * handle - controls whether the box is open (displaying its annotations) or closed. The handle appears in solid form if there are (interesting) annotations to display, otherwise it appears in outline form.
Each of these elements also functions as an affordance for action. For instance, clicking on a box's prototype indicator can select the box's prototype, or change it. Clicking on the name or value accesses similar functionality. The actions selected by clicks can be customized through click tables; see 4.4.3.
Graphic objects are implemented by special frames called actors that live in theaters. Theaters offer two views of their objects, a cast view and a stage view. Both the cast and stage are frames themselves, and the actor frames are actually contained within the cast frame and draw themselves in the stage frame. The two views of the objects are interconstrained (so that, for instance, dragging an object will continuously update the relevant slot displays). In Figure 4.3, simple-world is a theater with the stage and cast visible as annotations. A library of basic actors is provided, which the programmer can clone and customize. These include various shapes, lines, turtle-like rotatable objects, and text-actors. The library itself is a theater and new objects are created by using the standard cloning commands. There is no need for specialized palette objects.
Figure 4.4: The library of graphic objects
Actors respond to roughly the same commands as boxes. Both may be cloned by the same mouse-keyboard gesture, for instance. Both may be dragged, although the meaning of dragging an actor is different from dragging a box. The meaning of gestures may be independently customized for both actors and boxes.
Composite actors can be created by making a separate theater and cloning its stage (see figure 4.5). Instead of another stage, this makes an actor that contains all the actors of the original stage as parts. The "inheritance" of parts is dynamic, which means that changes in the original parts are immediately reflected in the composite.
Figure 4.5: Composite actors. The theater on the right
allows the parts of the face to be manipulated; while on the left the face
is a single actor.
The link between graphic and non-graphic objects may help novices who are experienced users of direct manipulation interfaces make the transition to programming, both by showing them a different view of their actions and by permitting them to interact with computational objects in a familiar way. On the other hand, the link between the graphic and box views is somewhat ad hoc and in conflict with the goal of making objects seem concrete by strongly identifying objects and their representation (see section 4.8.1).