In the first three sections you have been given a brief introduction to CLIM and some of its features. This section addresses the nature of CLIM in a more concrete and tangible fashion by defining important CLIM terms and discussing the fundamental elements of CLIM, as well as higher-level facilities that have been built from this core.
An application frame, or simply a frame, is the locus of all application-specific knowledge. It is a physical, bordered object that is composed of smaller, individually functioning parts, called panes. The frame maintains information regarding the layout of these components, keeps track of the Lisp state variables that contain the state of the application, and optionally has an interface to the window manager.
In developing a simple application such as an on-line address book, the application frame could be divided into several units to accomplish various tasks, as you can see in 1.4.1.2 Panes. One pane could be used to accept commands; another section of the screen could provide an index of names in the address book; another portion could be used to display a specific address entry. We might also choose to have a general menu and a few conveniently placed scroll bars. Each of these components of the application frame is a pane.
A pane is a window-like object that knows how to behave as a component of an application frame. That is, it supports the pane protocol operations for layout.
Panes come in many different varieties. For example, gadget panes include such things as buttons and scroll bars. Stream panes deal specifically with text. Some panes are defined only in terms of their functionality, without regard to their specific appearance or implementation. These panes are called abstract panes. The abstract definition allows various instances of the pane class to take on a platform-dependent look and feel. Panes can also be classified according to their role in pane hierarchies. Panes that can have child panes are called composite panes; those that cannot are called leaf panes. Composite panes that are in charge of spatially organizing their children are called layout panes.
An Example of Panes Within an Application Frame
The address book application frame shows a typical pane hierarchy. There are three instances of text panes that have associated scroll bars. For every extended stream pane, or text field, with affiliated scroll bar panes there is an "invisible" parent pane, known as a scroller pane, which does such things as control the layout of the child panes and ensure that its children are given the space they need.
The ability to address space allocation and composition concerns is the primary characteristic that sets panes apart from their superclass, sheets, to be discussed in 1.4.1.3 Sheets. Panes, therefore, understand how much screen space they want and need. For instance, the menu pane in the address book application has a static height, so that if the window is resized, the menu pane will not be scaled vertically. On the other hand, the scroller pane labeled in 1.4.1.2 Panes (the pane controlling the application pane for the address book index and the gadget panes for the two associated scroll bars) can be resized as long as the scroll bars are granted enough screen space to function, that is to say, to display the minimum graphics necessary to implement scrolling.
Panes are built from more general objects called sheets. Sheets are the fundamental "window-like" entities that specify the areas of the screen to be used for input and output interactions. Sheets consist of, in part, a region on the screen, a coordinate system, and optionally a parent and/or child sheets. For a complete discussion on sheets, refer to 18 Sheets. CLIM programmers will typically not need to deal with sheets directly, but instead will use the higher-level pane objects.
A pane hierarchy must be attached to a display server so as to permit input and output. This is handled by the use of ports and grafts. A port specifies the device acting as the display server, whereas grafts are special sheets, typically representing the root window, which are directly connected to the display server. (The term graft is derived from the horticultural practice of grafting, in which the trunk of one tree is joined onto the rootstock of another.) Again, a CLIM application programmer will not normally deal with these objects directly. A call to make-application-frame automatically results in a port specification and graft instantiation. Refer to 9.2 Defining CLIM Application Frames for details.
Once your panes are ready to accept output, you may be interested in creating graphics. CLIM provides elementary graphic functions such as draw-point and draw-circle as well as higher-level graphic functions such as draw-arrow and make-elliptical-arc (see 3.2 Using CLIM Drawing Options). CLIM also supports region operations such as region-intersection and region-difference (see 2.5 General Geometric Objects in CLIM).
The fundamental function for displaying text is draw-text. In addition to many of the graphic drawing options, text functions take a text-style argument that controls the font, face, and size.
An event is a CLIM object that represents some sort of user gesture (such as moving the pointer or pressing a key on the keyboard) or that corresponds to some sort of notification from the display server. Event objects store such things as the sheet associated with the event, the x and y position of the pointer within that sheet, the key name or character corresponding to a key on the keyboard, and so forth.
Graphical operations performed on panes must ultimately be carried out by the window system of the underlying host computer. This is accomplished primarily via communication with an underlying object called a medium. A medium understands how to implement CLIM graphics operations, such as draw-line, by calling the underlying host window system's graphics functions. A medium also contains default drawing options, such as foreground and background colors, clipping region, transformations, line thickness, and fonts. There are different medium classes to support different windowing systems; thus, there is one medium class for the X Window System and a different one for the Macintosh Common Lisp environment.
This host-specific behavior is kept in a separate medium so that the pane classes themselves will be host-independent. Thus, when you build a new pane class, you do not have to build one version with X graphics mixed in, another one for the Mac, and so forth.
CLIM application programmers will not usually deal with mediums directly. In most cases, panes will automatically be allocated a medium upon creation, and output directed to the pane will be appropriately forwarded to the medium. In situations where efficiency is a concern, you may choose to send graphical output directly to the underlying medium. There are also situations, particularly when a pane has infrequent output, when you may wish to have many "light-weight" panes that share a medium.
CLIM provides many higher-level facilities that are built from the fundamental CLIM elements.
CLIM offers a variety of tools and features for creating portable Lisp applications. One of these techniques, made possible by the adaptive toolkit, is the ability to transform the look and feel of a given application easily. Thus, an application can take on Motif characteristics when running on a Unix workstation, can have a Microsoft Windows look and feel when running on that platform, or can be presented in a different customized manner.
Frame managers are responsible for controlling the look and feel of an application frame. Each different kind of appearance, whether it be Motif or Microsoft Windows, is expressed by a different frame manager. CLIM provides frame managers that interface to a large number of host environments, including X Windows. There is also a "generic" frame manager that allows applications to maintain a "CLIM look and feel" across all platforms, rather than adopting the style of the underlying windowing system. Existing frame managers can be customized, or entirely new frame managers can be created to give your application the look and feel you desire.
A frame manager is responsible for interpreting the portable, window-system-independent layout specification of an application frame in the context of the look and feel supported by the frame manager. The abstract gadget panes, such as the scroll bars and buttons, will be mapped into specific pane classes that implement the gadget in terms of the native gadget of the host window system. For example, scroll-bar is mapped onto internal classes which use the SCROLLBAR control on Microsoft Windows and the ScrollBar widget on Motif.
Because Common Lisp performs its input and output on objects called streams, CLIM does, too. In CLIM, streams are specialized sheets that implement the sheet and stream protocols. The basic stream protocols for input and output provide fundamental functionality such as reading and writing characters and flushing the output. Stream input is provided by low-level events; stream output is accomplished through low-level graphics.
Streams in CLIM also support extended input and output protocols. The extended input stream protocol handles issues pertaining to, in part, non-character input such as mouse clicks. The extended output stream protocol addresses advanced issues such as text cursors, margins, text styles, inter-line spacing, and output recording.
Output recording is a facility CLIM offers for capturing all output done to an extended stream. This information is stored in structures called output records. Output recording is used in the implementation of scrollable windows and incremental redisplay. See 14 Output Recording and Redisplay and 15 Extended Stream Input Facilities for more details.
The presentation facility extends output recording to remember the semantics of output displayed in a CLIM window. Presentations are specialized output records that remember not only output, but also the Lisp object associated with the output and the semantic type affiliated with that object. This semantic type, called the presentation type, allows display objects to be classified. Such semantic tagging allows the user to re-use existing output on the window to satisfy future input requests.
When a CLIM application is expecting input, an input context is established, which means the application is awaiting input of a certain semantic type. Presentations with an appropriate presentation type for the input context become sensitive; that is to say, clicking on them with the mouse will cause some action to happen. For instance, in the previous address book application example, when entering a new address, a user could type in an address or could specify input by clicking on any sensitive presentation. Addresses would be the only logical entry in this case, so only address presentation types will be sensitive. Nothing would happen if you clicked on a name or a phone number.
In a specific input context, when a given presentation type is valid input, all of the subclasses of this type are also acceptable. There are many cases, however, in which you may wish to expand the list of valid presentation types for a given input context. This is possible by the use of presentation translators.
The outermost level of an application is an infinite interaction processing loop, similar to the Lisp read-eval-print loop, called a command loop. The arguments to commands are defined in terms of the presentation type facility, so that command arguments can be specified via keyboard or mouse input.
It is also possible to map presentation types to commands that operate on arguments of those types. Thus you can invoke commands by clicking on displayed data. For example, in the address book example, as the command loop awaits commands, any command display objects would be sensitive. By using the define-presentation-to-command-translator macro, however, many other presentation types can in effect be turned into commands. A click on a name in the index could represent the "Select Address" command. Similarly, clicking on a field in the displayed address, such as the "Number:" field, could be translated into the "Change Address Number" command, as illustrated in Using Presentation-to-Command Translators.
The CLIM core, comprising of sheets, mediums, graphics, and input and output, serves as the foundation for higher-level functionality. CLIM itself provides many advanced capabilities that have been developed from this kernel. Presentations, streams, and gadgets are all descendants of the fundamental CLIM kernel. This resulting hierarchy of objects and functionality gives CLIM a layered structure. For instance, we notice that streams and gadgets are specialized panes that are themselves specialized sheets. Similarly, presentations are customized output records. At any point in these hierarchies, one may customize and specialize objects by making subclasses of existing objects and adding the desired functionality. Although CLIM provides many advanced facilities, it is always possible to return to the fundamental CLIM building blocks and start creating anew.
CLIM 2.0 User Guide - 01 Dec 2021 19:38:55
