User-Defined Data Types as Presentation Types

Whenever you use defstruct, defflavor, or deftype, you are creating a new data type. Often, when you have defined such a data type, you wish to present and

accept objects of the new type in you programs. Should you present them with the presentation type being the same as the data type, or invent a separate presentation type, instead? When addressing this issue, you need to consider mouse handlers both from the data type in question, and to the data type. It is important to remember that all data types are subtypes of sys:expression.

These issues also arise when defining presentation types in terms of data-types, for example, defining odd-integer to be an :abbreviation-for « and integer

«satisfies oddp)))).

Let's consider handlers from the new type first. If you define a handler from your type, this handler will apply to instances of your object that you present, or that are printed out by the debugger while you are debugging your program. This is as it should be. However, the handler might apply to other presentations as well.

In the case of odd-integer, for example, whenever you move the mouse over an odd integer - whether it was explicitly presented as type odd-integer or not - the handler will apply. You may approve of this behavior, but if not, then do not define odd-integer in terms of integer; that way, the handler is only available when explicitly asked for.

In the case of flavors and structures, if you wish to restrict the applicability of handlers from your type to only those objects presented explicitly as this type, then define the presentation type with a name different from the flavor or structure.

Similar considerations apply to handlers to your type. If you define a translator with a to-presentation-type that is also a data type, remember- that it will apply in the sys:expression input context, because such an object is also a type of

expression. In particular, it will apply at the Lisp top leve1. Again, this mayor may not be appropriate from your point of view. If not, the solutions are the same.

The following example should make both of these situations clearer. (The translator in this example is intentionally slow.)

(defstruct family-tree father

mother)

(fs:define-canonical-type :family-tree "FAMILY-TREE"

«:unix :unix42 :vms :vms4) "FAT")) (defun family-tree-file-p (pathname)

(eql (send pathname :canonical-type) :family-tree)) (define-presentation-type family-tree-pathname ()

:expander J«and pathname «satisfies family-tree-file-p)))))

(define-presentation-translator pathname-to-family-tree (family-tree-pathname front type

family-tree ; to type :gesture :select)

(pathname)

(with-open-file (file pathname (read file)))

:direction :input

:element-type 'characters) (cp:define-command (com-show-family-tree-directory

:command-table "GLOBAL") ()

(loop for x in (directory (send (fs:user-homedir) :new-pathname :name :wild

:type :family-tree :version :newest)) do (present x 'family-tree-pathname)))

(cp:define-command (com-count-family-tree-generations :command-table "GLOBAL")

«family-tree 'family-tree)) (labels «count (tree)

(if (null tree) e

(1+ (max (count (family-tree-father tree)) (count (family-tree-mother tree))))))) (format t "The number of generations is -D."

(count family-tree))))

In this example, pointing the mouse at a pathname that has the :family-tree canonical type highlights the presentation. This occurs even if the pathname is displayed as a result of a Show Directory command instead of a Show Family Tree Directory command; or if it results from evaluating

(fs:parse-pathname "ACME:>ui-programmer>my-family.family-tree) in a Lisp Listener. If this behavior is unwanted, then the

:expander '«and pathname «satisfies family-tree-file-p)))) should be omitted from the type's definition.

Also, the pathname-to-fami 1 y-tree translator applies even if you are not looking specifically for a family tree. If you are accepting a sys:expression, perhaps in the Lisp Listener's command loop, you are offered the option of reading in the file.

The programmer's intent was to make the pathnames displayed by Show Family Tree Directory sensitive only in the family-tree input context, as produced by the Count Family Tree Generations command. There are two ways to get this

behavior. The first is to rename the structure or the presentation type, for example,

(defstruct (family-tree-instance (:conc-name "FAMILY-TREE-") (:constructor make-family-tree»

father mother)

However, sometimes it might be inconvenient to make the presentation type and the name different. In such cases, a :tester function can be supplied to the handler that uses dw:handler-applies-in-limited-context-p to limit the handler to cases where the program explicitly requests a family-tree.

Another problem with the translator, as written, arises when the input context is family-tree and the user moves the mouse over one of these pathnames. Because SemantiCue evaluates the body to see if the handler applies, the file is read in without the user even clicking the mouse. This problem could be prevented in two ways. First, we could put : do-nat-compose t in the option list for the translator. This suppresses the evaluation of the body to check its return value.

Unfortunately, it also means that if we did

(accept J((and family-tree ((satisfies dad-named-george-p»») the predicate dad-named-george-p would never be run.

Alternatively, the program could be remodularized, with a command that worked on files instead of family-trees. Here is our example rewritten, to take all of these considerations into account.

(defstruct family-tree father

mother)

(fs:define-canonical-type :family-tree "FAMILY-TREE"

((:unix :unix42 :vms :vms4) "FAT"»

(defun family-tree-file-p (pathname)

(eql (send pathname : canoni cal-type) : fami 1 y-tree»

(define-presentation-type family-tree-pathname ()

JJ It is not unreasonable for any pathname with the type

;; of :family-tree to be available as a

;; family-tree-pathname J so we leave this in.

:expander J((and pathname ((satisfies family-tree-file-p»»)

(cp:define-command (com-show-family-tree-directory :command-table "GLOBAL") () (loop for x in (directory (send (fs:user-homedir)

:new-pathname :name :wild

:type :family-tree :version :newest»

do (present x 'family-tree-pathname») (defun count-family-tree-generations (tree)

(i f (null tree) 9

(1+ (max (count-family-tree-generations (family-tree-father tree»

(count-family-tree-generations (family-tree-mother tree»»»

(cp:define-command (com-count-family-tree-generations :command-table "GLOBAL")

«family-tree 'family-tree»

(format t "The number of generations is -D."

(count-family-tree-generations family-tree») (cp:define-command (com-count-family-tree-file-generations

:command-table "GLOBAL")

«pathname 'family-tree-pathname»

(with-open-file (file pathname

:direction :input

:element-type 'character) (let «family-tree (read file»)

(format t "The number of generations is -D."

(count-family-tree-generations family-tree»»)

An advanced concepts section in the overview of mouse handler facilities presents information pertinent to the above discussion: See the section "Advanced Mouse Handler Concepts", page 42.