Event-Driven Programming
Figure 27.1 shows a program that progresses from time T0 to T6 in two states: a processing state in which program instructions are executed and an input state in which program execution is suspended until user input arrives.
After some program initialization starting at time T0, the program ignores user input until it reaches time T1. At T1, the execution of the program is suspended until fgets(3) receives input (using an underlying read(2) system call). At time T1 the program is attentive to the user.
At time T2, however, the program is busy executing instructions that pertain to database queries and other non-input activities. The user cannot direct the flow of the program at this point.
Figure 27.1. Non–event-driven states from time T0 to T6.
At time T3, the program is willing to listen to the user again, providing the user some measure of control. However, after this input is received, at time T4 the program completely ignores the user as it chugs away.
Time T5 allows the user one more opportunity for input before ignoring the user again at time T6. Throughout the entire execution of the program, it has only allowed user control over it at a few defined points.
An Event-Driven Model
Figure 27.2 shows how an event-driven model behaves.
Figure 27.2. Event-driven states from time T0 to T6.
In this program, there is some initialization starting at time T0. However, from time T1 to T5 the program is preoccupied with obtaining input events from the user. Only after an input event occurs does the program ignore input briefly to process the action required by the event.
The fact that event-driven models also ignore input briefly highlights one important aspect of graphical programming: Event processing must be brief. Otherwise, the user will cease to have control. Note that, like character mode programs, graphical events are queued for the event-driven program. This allows event programs to process events without losing them as it performs processing for the preceding events.
Client/Server Processing
The X Window graphic software is flexible enough to allow programs to draw graphics on the local screen or to a remote computer's screen instead. The X Window server is the process that manages the input devices and the one or more display screens. The client is the program that wants to draw on the screen and receive input from the input devices, such as the mouse and keyboard. Figure 27.3 shows an X Window server running on host alpha and clients running on all three hosts.
Figure 27.3. Four X Window client programs using one X Window server.
The X Window server running on host alpha controls the graphics display screen, the keyboard, and the mouse. On the same host, a client program is making use of these facilities through a local socket connection to the server.
On host beta, one client is accessing the alpha X Window server through the network. Host gamma has two client programs accessing the alpha X Window server through the network.
The user sitting at the display has four different windows open. Each window sends input events to the specific client program that created the window.
Software Layers
Graphical programming tends to be complex. To make the software easier to design and manage, the X Window software has been designed in layers. Figure 27.4 shows a conceptual view of this.
Figure 27.4. X Window software layers.
Figure 27.4 shows three client program perspectives. These are common configurations for X Window clients but not the only ones available. Application program A uses the basic X Window library Xlib. This library eliminates the need for the client program to know the X Window protocol. The Xlib library allows the programmer to concentrate on the input and the drawing events instead.
Application program B uses an X Toolkit library, which then calls upon the Xlib library. The Toolkit library provides a basic framework for X Window widget support and uses Xlib to provide lower-level support. This simplifies the application's handling of menus, buttons, and other widgets.
Application program C uses the MOTIF library, which calls upon the X Toolkit and the Xlib libraries. The MOTIF library provides a fully functional set of widgets with a 3D look and includes support for other languages.
Application program C is the simplest program to write if the application involves pushbuttons, list boxes, text entry fields, and so on. However, if your application requires only drawing facilities, the Xlib support may be all you need.
The example program presented in this chapter will be of the application A variety. Using the Xlib library is sufficient for demonstrating event-driven programming and requires the least amount of explanation. The serious X Window programmer is encouraged to read more about the X Toolkit and MOTIF libraries, however.