Page 284	Table of Contents	Index	Page 286
	Chapters
	1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 A, B, C, D, E

---

CHAPTER 28. APPLICATION FRAMES

displayed with their own frames. For example, a text editor might allow figures generated by
a graphic editor to be edited in place by managing the graphics editor's frame within its own
frame.

Application frames provide support for a standard interaction processing loop, like the Lisp
"read-eval-print" loop, called a command loop. The application programmer has to write only
the code that implements the frame-specific commands and output display functions. A key
aspect of the command loop is the separation of the specification of the frame's commands from
the specification of the end-user interaction style.

The standard interaction loop consists of reading an input "sentence" (the command and all of
its operands), executing the command, and updating the displayed information as appropriate.
CLIM implementations are free to run the display update part of the loop at a lower priority
than command execution, for example, some implementations may choose not to update the
display if there is typed-ahead input. Note that by default command execution and display will
not occur simultaneously, so user-defined functions need not have to cope with multiprocessing.
Of course, the programmer can use multiple processes, but CLIM neither directly supports nor
precludes doing so.

To write an application that uses the standard interaction loop provided by CLIM, an application
programmer does the following:

• Defines the presentation types that correspond to the user interface entities of the appli-
  cation.
  
  
• Defines the commands that correspond to the visible operations of the application, speci-
  fying the presentation types of the operands involved in each command.
  
  
• Defines the set of frames and panes needed to support the application.
  
  
• Defines the output display functions associated with each of the panes (possibly using other
  facilities such as the incremental redisplay).

Taking as an example a simple ECAD program, the programmer would first define the ap-
propriate presentation types, such as wires, input and output signals, gates, resistors, and so
forth. He would then define the program's commands in terms of these types. For example, the
"Connect" command might take two operands, one of type "component" and the other of type
"wire". The programmer may wish to specify the interaction style for invoking each command,
for example, direct manipulation via translators, or selection of commands from menus. After
defining an application frame that includes a CLIM stream pane, the programmer then writes
the frame-specific display routine that displays the circuit layout. Now the application is ready
to go. The end-user selects a command (via a menu or command-line, or whatever), the top-level
loop takes care of collecting the operands for that command (via a variety of user gestures), and
then the application invokes the command. The command may have a side-effect on the frame's
"database" of information, which can in turn affect the output displayed by the redisplay phase.
Note that this definition of the standard interaction loop does not constrain the interaction style
to be a command-line interface. The input sentence may be entered via single keystrokes, pointer
input, menu selection, dialogs, or by typing full command lines.

---

Page 284	Table of Contents	Index	Page 286
	Chapters
	1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 A, B, C, D, E