In object-oriented programming systems, applications are built around internal objects that model something in the real world. For example, an application that models a university has objects representing students, professors, and courses. A CAD system for designing circuits has objects representing gates, resistors, and so on. A desktop publishing system has objects representing paragraphs, headings, and illustrations.
Application objects have to be presented to the user, and the user has to be able to interact with them. In CLIM, an interface enables the user to see visual representations of the application objects and, via these representations, operate on the application objects themselves.
A very basic part of designing a CLIM user interface is specifying how the user will interact with application objects. There are two directions of interaction: you must present application objects to the user as output, and you must accept input from the user that indicates application objects. This is done with two basic functions, present and accept, plus some related functions.
CLIM keeps track of the association between a visual representation of an object and the object itself. CLIM maintains this association in a data structure called a presentation. A presentation embodies three things:
In other words, a presentation is a special kind of output record that remembers not only output, but the object associated with the output and the semantic type associated with that object.
A presentation type can be thought of as a CLOS class that has some additional functionality pertaining to its roles in the user interface of an application. In defining a presentation type, the application programmer defines all of the user interface components of the entity:
In other words, the application programmer describes in one place all the information about an object necessary to display it to the user and interact with the user for object input.
For example, a university application has a "student" application object. The user sees a visual representation of a student, which might be a textual representation, a graphical representation (such as a form with name, address, and student id number), or even an image of the face of the student. The presentation type of the student is "student"; that is, the semantic type of the object that appears on the screen is "student." Since the type of a displayed object is known, CLIM knows which operations are appropriate to perform on the displayed object. For example, when a student is displayed, it is possible to perform operations such as send-tuition-bill or show-transcript.
Presentations are the basis of many of the higher-level application-building tools that use accept to get input and present to display output. A command that takes arguments as input specifies the presentation type of each argument. When a call to accept is made, CLIM establishes an "input-context" based on the presentation type. This input context is used to determine which presentations will be sensitive to mouse clicks. For instance, when a user gives the send-tuition-bill command, the input context is of type "student," so any students displayed—both those being displayed for the first time and those that have been displayed before—are sensitive. This is because presentations that have been output in previous user interactions retain their semantics; that is, CLIM has recorded the fact that a student has been displayed and has saved this information.
CLIM presentation types are designed to use inheritance, just as CLOS classes do. For example, a university might need to model "night-student," which is a subclass of "student." When the input context is looking for a student, night-students are sensitive because they are represented as a subtype of student.
The set of presentation types forms a type lattice, an extension of the Common Lisp CLOS type lattice. When a new presentation type is defined as a subtype of another presentation type, it inherits all the attributes of the supertype except those explicitly overridden in the definition.
You can define presentation translators to make the user interface of your application more flexible. For example, suppose the input context is expecting a command. In this input context, all displayed commands are sensitive, so the user can point to one to execute it. However, suppose the user points to another kind of displayed object, such as a student. In the absence of a presentation translator, the student is not sensitive because only commands can be entered to this input context.
In the presence of a presentation translator that translates from students to commands, however, both students and commands would be sensitive. When the student is highlighted, the middle pointer button might execute the command show-transcript for that student.
By the time you get to the point of designing the user interface, you have probably designed the rest of the application and know what the application objects are. At this point, you need to do the following:
CLIM 2.0 User Guide - 01 Dec 2021 19:38:57