CLIM panes are similar to the gadgets or widgets of other toolkits. They can be used to compose the top-level user interface of applications as well as auxiliary components such as menus and dialogs. The application programmer provides an abstract specification of the pane hierarchy, which CLIM uses in conjunction with user preferences and other factors to select a specific "look and feel" for the application. In many environments, a CLIM application can use the facilities of the host window system toolkit via a set of adaptive panes, allowing a portable CLIM application to take on the look and feel of a native application user interface.
Panes are rectangular objects that are implemented as special sheet classes. An application will typically create a tree of panes that divide up the application frame's screen space. Panes can be structurally classified according to their location in pane hierarchies. Panes that can have child panes are called composite panes; those that cannot are called leaf panes. Composite panes are used to provide a mechanism for spatially organizing ("laying out") other panes. Some leaf panes implement gadgets that have some appearance and react to user input by invoking application code. Another kind of leaf pane, known as an extended stream pane, provides an area of the application's screen real estate for the presentation of text and graphics.
Abstract panes are panes that are defined only in terms of their programmer interface, or behavior. The protocol for an abstract pane (that is, the specified set of initialization options, accessors, and callbacks) is designed to specify the pane in terms of its overall purpose, rather then in terms of its specific appearance or particular interactive details. This abstract definition allows multiple implementations of the abstract pane to define their own specific look and feel individually. CLIM can then select the appropriate pane implementation based on factors outside of the application domain, such as user preferences or the look and feel of the host operating environment. A subset of the abstract panes, the adaptive panes, have been defined to integrate well across all CLIM operating platforms.
CLIM provides a general mechanism for automatically selecting the particular implementation of an abstract pane selected by an application based on the current frame manager. The application programmer can override the selection mechanism by using the name of a specific pane implementation in place of the abstract pane name when specifying the application frame's layout. By convention, the name of the basic, portable implementation of an abstract pane class can be determined by adding the suffix -pane to the name of the abstract class.
Applications typically define the hierarchy of panes used in their frames with the :pane or :panes options of define-application-frame. These options generate the body of methods on functions that are invoked when the frame is being adopted into a particular frame manager, so the frame manager can select the specific implementations of the abstract panes.
There are two basic interfaces for constructing a pane: make-pane of an abstract pane class name, or make-instance of a "concrete" pane class. The former approach is generally preferable, since it results in more portable code. However, in some cases the programmer may wish to instantiate panes of a specific class (such as an hbox-pane or a vbox-pane). In this case, using make-instance directly circumvents the abstract pane selection mechanism. However, the make-instance approach requires the application programmer to know the name of the specific pane implementation class that is desired, and so is inherently less portable. By convention, all of the concrete pane class names, including those of the implementations of abstract pane protocol specifications, end in -pane.
Using make-pane instead of make-instance invokes the "look and feel" realization process to select and construct a pane. Normally this process is implemented by the frame manager, but it is possible for other "realizers" to implement this process. make-pane is typically invoked using an abstract pane class name, which by convention is a symbol in the CLIM package that does not include the -pane suffix. (This naming convention distinguishes the names of the abstract pane protocols from the names of classes that implement them.) Programmers, however, are allowed to pass any pane class name to make-pane, in which case the frame manager will generally instantiate that specific class.
Summary: The protocol class that corresponds to a pane, a subclass of sheet. A pane is a special kind of sheet that implements the pane protocols, including the layout protocols. If you want to create a new class that behaves like a pane, it should be a subclass of pane. Subclasses of pane must obey the pane protocol.
All of the subclasses of pane are mutable.
panep object
Summary: Returns t if object is a pane; otherwise, it returns nil.
Summary: The basic class on which all CLIM panes are built, a subclass of pane. This class is an abstract class, intended only to be subclassed, not instantiated.
make-pane abstract-class-name &rest initargs
Summary: Selects a class that implements the behavior of the abstract pane abstract-class-name and constructs a pane of that class. make-pane must be used either within the dynamic scope of a call to with-look-and-feel-realization, or within the :pane or :panes options of a define-application-frame (which implicitly invokes with-look-and-feel-realization).
make-pane-1 realizer frame abstract-class-name &rest initargs
Summary: The generic function that is invoked by a call to make-pane. The object that realizes the pane, realizer, is established by with-look-and-feel-realization. Usually realizer is a frame manager, but it could be another object that implements the pane realization protocol. frame is the frame for which the pane will be created, and abstract-class-name is the type of pane to create.
with-look-and-feel-realization Macro
with-look-and-feel-realization (realizer frame) &body forms
Summary: Establishes a dynamic context that installs realizer as the object responsible for realizing panes. All calls to make-pane within the context of with-look-and-feel-realization result in make-pane-1 being invoked on realizer. This macro can be nested dynamically; inner uses shadow outer uses. body may have zero or more declarations as its first forms.
realizer is usually a frame manager, but in some cases realizer may be some other object. For example, within the implementation of a pane that uses its own subpanes to achieve its functionality, this form might be used with realizer being the pane itself.
The following options must be accepted by all pane classes.
:foreground
:background Options
Summary: These options specify the default foreground and background inks for a pane. Client code should be cautious about passing values for these two options, since the desktop's look and feel or the user's preferences should usually determine these values.
Summary: This option specifies the default text style that should be used for any sort of pane that supports text output. Panes that do not support text output ignore this option. Client code should be cautious about passing values for this option, since the desktop's look and feel or the user's preferences should usually determine this value.
Summary: This option specifies the name of the pane. It defaults to nil.
pane-frame pane
Summary: Returns the frame that "owns" the pane. pane-frame can be invoked on any pane in a frame's pane hierarchy, but it can only be invoked on "active" panes, that is, those panes that are currently adopted into the frame's pane hierarchy.
pane-name pane
Summary: Returns the name of the pane.
pane-foreground Generic Function
pane-foreground pane
Summary: Returns the foreground ink of the pane.
pane-background Generic Function
pane-background pane
Summary: Returns the background ink of the pane.
CLIM 2.0 User Guide - 01 Dec 2021 19:38:58