The core around which the CLIM application user interface model is built is the concept of the application-defined user interface data type. Each application has its own set of semantically significant user interface entities; a CAD program for designing circuits has its various kinds of components (gates, resistors, and so on), while a database manager has its relations and field types. These entities have to be displayed to the user (possibly in more than one displayed representation) and the user has to be able to interact with and specify the entities via pointer gestures and keyboard input. Frequently each user interface entity has a corresponding Lisp data type (such as an application-specific structure or CLOS class definition), but this is not always the case. The data representation for an interaction entity may be a primitive Lisp data type. In fact, it is possible for several different user interface entities to use the same Lisp data type for their internal representation, for example, building floor numbers and employee vacation day totals could both be represented internally as integers. [annotate]
CLIM provides a framework for defining the appearance and behavior of these user interface entities via the presentation type mechanism. 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. By defining a presentation type the application programmer defines all of the user interface components of the entity: [annotate]
[presentation type, Concept← A Glossary]
[presentation type, Concept← A Glossary]
[presentation type, Concept← A Glossary]
[presentation type, Concept← A Glossary]
[presentation type, Concept← 23.5 Context-dependent (Typed) Input, prompt-for-accept-1]
[presentation type, Concept← 23.5 Context-dependent (Typed) Input, prompt-for-accept]
[presentation type, Concept← 23.5 Context-dependent (Typed) Input, with-input-context]
[presentation type, Concept← 23.4 Typed Output, present]
[presentation type, Concept← 23.3.3 Presentation Methods, presentation-default-preprocessor]
[presentation type, Concept← 23.3.3 Presentation Methods, presentation-type-history]
[presentation type, Concept← 23.3.3 Presentation Methods, map-over-presentation-type-supertypes]
[presentation type, Concept← 23.3.3 Presentation Methods, presentation-subtypep]
[presentation type, Concept← 23.3.3 Presentation Methods, presentation-subtypep]
[presentation type, Concept← 23.3.3 Presentation Methods, presentation-typep]
[presentation type, Concept← 23.3.3 Presentation Methods, presentation-type-specifier-p]
[presentation type, Concept← 23.3.3 Presentation Methods, describe-presentation-type]
[presentation type, Concept← 23.3.3 Presentation Methods, accept]
[presentation type, Concept← 23.3.3 Presentation Methods, present]
[presentation type, Concept← 1 Overview of CLIM]
In other words, by defining a presentation type, 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. [annotate]
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. [annotate]
Minor issue: Describe what a presentation type is more exactly. What is a parameterized presentation type? Why do we want them? Why are they in a lattice? How do they relate to CL types and CLOS classes? What exactly gets inherited? --- SWM [annotate]