The Resource Database

Before a user can assign a resource value to a particular UI object, he must have a way of identifying it, some kind of name which can be referenced outside of the program which creates the object. Remember that a contact has a name slot; this is a symbol that could certainly help identify the contact. Consider also that a contact is generally part of a nested hierarchy of UI objects. For example, a paint program might have pattern choice contact which contains several button contact children, one for each available pattern style. A more complete name for a button child would be a list which also includes its parent's name, e.g. '(pattern-choice checkered). We can extend this notion all the way up the hierarchy to come up with a complete resource name for the checkered pattern button. This would be a list of resource name symbols, starting with the resource name for the program itself (i.e. the required argument to open-contact-display) and continuing with symbols for the root ancestor, the top-level ancestor, and so on: 

    '(paint screen-1 pattern-choice checkered)

Assuming that the checkered button has a resource for its label string named label and another resource for the label font named font, then the complete names for these resources would obviously be: 

    '(paint screen-1 pattern-choice checkered label)
    '(paint screen-1 pattern-choice checkered font)

As you might expect when dealing with long path names like these, it's often useful to insert ``wildcards'' in the places where you don't want to be so specific. For example, the following resource name would refer to the font of everything in the pattern choice contact, regardless of the screen where it appears: 

    '(paint * pattern-choice * font)

Another way of identifying a contact is by its object class. So, for example, you could refer to the font of every button object in the paint program with the following resource name. 

    '(paint * button font)

By associating values with these sorts of resource names in resource bindings, a user can create a resource database which represents his UI preferences. CLUE provides a define-resources macro for adding resource bindings to the database. 

(define-resources
  (paint * button background)               white
  (paint * pattern-choice * font)           helvetica-12
  (paint * pattern-choice checkered label) "Checkered")

CLUE automatically reads the resource database whenever a contact is created. A contact has a class and possibly other contact superclasses on its class precedence list. Each such (super)class has a list of resource names that it uses (defined by the :resources option of the defining defcontact form). Together, these form the set of contact resources that are looked up in the resource database. Of course, finding a resource value is rather complicated, because names in the database may not be complete resource names and may contain a mixture of resource names and class symbols. Nevertheless, during initialization, CLUE will find the resource binding that is the closest match for each contact resource. In general, a contact gets its resource values first from the user's resource database, then from programmer-specified defaults when no user value is found.

\framebox[5.5in]{ \hspace*{\fill} {\bf Note} \hspace*{\fill} \parbox[t]{4.5in}{ ... ...{\tt defcontact} form for his contact class.\index{defcontact}} \hspace*{\fill}}