Graphic Objects

Simple Graphic Objects

Now we can make databases and attach demons to entries them. The last remaining to define what a graphic object is and add code for making demons that instantiate them.

We will define a graphic type, or gob, to have the following form:

(defstruct gob
  unchanging
  changing)

Please note that a gob is an archetypal graphic object. The dial gob will not be attached to any database field, for example, but will be the source from which particular dials are instantiated.

A has two fields for the sake of efficiency. A graphic object might be be a very complex picture, only a few of parts of which ever change. In a clock, for example, only the hands have to be re-drawn. The unchanging field of a gob contains a function that draws the immutable parts of a graphic object (the clockface) and the changing field contains a function draws the moving parts (the hands). When you have a screen full of complicated graphic objects, the time required to update them all becomes a serious issue.

We will use our database utilities to keep track of the gobs themselves:

(setq gobs (make-db))

When we need to find the dial gob, we can look it up in this database under the key dial.

The gobs given as examples here use a very limited subset of graphics commands. Any LISP system with graphics will offer something like them. The commands are:

(wmake x y width height title)
(point window x y)
(line window x1 y1 x2 y2)
(circle window x y radius)
 

The first function returns new windows and the remaining functions draw on them. They all do just what they appear to do, except in one respect. When the drawing functions put pixels on a window, they exclusive-or (xor) them with the pixels already there. Almost all window systems allow this.

The advantage of xoring is that when you xor the same picture twice, the screen is returned to its initial state. That's why, when attach-gob calls add-demon, it gives the same function as both the pre-fn and post-fn. The disadvantage of xoring is that when two black lines intersect, the intersection is white -- but this is a small price to pay for the convenience it brings.

Listing Four contains all the code needed to define and instantiate gobs. The function defgob is very straightforward -- it just makes a gob and stores it away.

(defun defgob (name unchanging changing)
   (db-update gobs name
   (make-gob : unchanging unchanging
             : changing changing))
   name)

(defun idfn (X) x)

(defun attach-gob (db key gobname window
                    &optional (scale 1)
                   (access-fn #'idfn))
   (let* ((gob (db-query gobs gobname))
      (valnow (funcall access-fn (db-query db key)))
      (dem (add-demon db key
          access-fn
          #'(lambda (val)
               (funcall (gob-changing gob)
               val window scale))
          #'(lambda (val)
               (funcall (gob-changing gob)
               val window scale)))))
    (funcall (gob-unchanging gob)
          valnow window scale)
    (funcall (gob-changing gob)
    valnow window scale)
    dem))

(defun attach-gobs (triples window &optional (scale 1))
   (dolist (trip triples)
   (apply #'(lambda (db key gobname)
            (attach-gob db key gobname window scale))
          trip)))

The following is just about the simplest possible gob:

(defgob 'simple
   #'nilfn
   #'(lambda (val window scale)
     (line window
        0 50
     (* val scale) 50)))

A simple gob represents the value to which it is attached as a horizontal line. It doesn't have any unchanging parts, and the only changing part is the line.

All gob functions are assumed by the demons that call them to have the three parameters shown in the definition of simple; the value being represented, the window in which the instantiation resides, and its scale.

The last remaining function needed to link all this code together is attach-gob, which instantiates one of the gob types (for example, simple) in a demon attached to some database entry. This is what it turns out to mean to "instantiate a gob": attach-gob makes a demon whose actions call the gob's changing function. Note that, as in our previous demons, these are closures, closed over the window in which the instance is to appear, and its scale.

Having created the demon, attach-gob starts the new graphic object off by drawing both its unchanging and changing parts. Finally, the newly created demon is returned. The last function, attach-gobs, makes it convenient to instantiate several gobs in a single window.

Now, with a single command, we can attach a graphic object to our pet database entry. First we make a window, then all we need do is call attach-gob with the database reference, the gob type, and the window (Listing Five).

> (setq our-window (wmake a a 100 100 "Our Window"))
#<Window. ..}
) (attach-gob our-db 'temperature 'simple our-window)
#S(DEMON. ..)

At this point the window should contain a line representing the fact that the temperature is 98. Having attached the graphic object, we can forget that it exists. When we change the temperature to something more pleasant, the graphic object gets updated automatically:

> (db-update our-db 'temperature 72)
72

This may seem like a lot of work just to represent a scalar value so simply. In fact, the code we have discussed is much more general than that. We can use it to attach any sort of graphic demons, not just graphic ones. When we do want to make new graphic objects, we can define new graphic objects, and even new types of graphic objects, on-the-fly. We can attach as many as we want to a database entry or to subparts of a database entry. We can even represent several graphic objects in one window.