17.12 EVENT PROCESSING IN GUI PROGRAMS

17.12 EVENT PROCESSING IN GUI PROGRAMS

When you run a GUI program, at its most basic level the interaction between a human user and the computer consists of events. To get a good sense what an event is, let's examine closely through Figure 17.22 as to what happens when you press a mouse button to interact with a GUI. An event is the information packet that is placed by the window manager in the event queue of the window in which the event was generated. This information packet contains the values for the x and the y coordinates of the mouse pointer when the mouse button was pressed and the identity of the button. The window manager's job is to keep track of the stacking order of the windows on a terminal screen and to ascertain from the coordinates of the mouse pointer as to which window generated the event. The window manager then simply places the event in the event queue of that window.

Figure 17.22

One of the main jobs of a GUI program is to run an event processing loop for a window for reacting to the events placed in the event queue of that window by the window manager. The very first step in event processing consists of determining the identity of the widget that is responsible for the event. If the event was caused by a user pressing a mouse button when the mouse pointer was on top of a GUI button, the GUI program would need to associate the event with that specific GUI button. Once this association is established, we could say loosely that the widget-the specific GUI button in this case-"emitted" the event or the signal.

After the source of an event is identified, one or more appropriate functions must be invoked in response to that event. Most modern GUI systems require a programmer to specify these functions explicitly in a program. These functions, called callbacks or callback functions, must somehow be "registered" with the widget that emitted the event. They are called callback functions because the GUI program does not invoke them explicitly. All a GUI program does is to set up an association between the event types that can be emitted by a widget and the callbacks that are to be executed in response to those event types. It is the underlying operating system that hands the flow of execution to a callback function when an event specific to a widget has been emitted.

How a callback function is registered with the source of an event varies considerably from system to system. In AWT/Swing, the callback functions are a programmer's implementations of functions in certain "listener" interfaces. An object must implement such an interface if it wishes to be notified of the occurrence of an event. Such an object must then be registered with the event-emitting widget with an "add" function. Qt, on the other hand, has a system of signals and slots for processing "high-level" events. Any object that wishes to be notified of a signal emitted by a widget must provide a slot for that signal. A slot is merely a function that can be made to respond to a particular signal by including both in a "connect" declaration. The signal from the emitting widget goes directly to the slot designated in the "connect" invocation. GNOME/GTK+ also uses a connect declaration for associating a signal with a callback.

An alternative to explicit registration of a callback with a signal is the use of polymorphic functions associated with signal-emitting widgets. So when a widget emits a signal, certain such functions are automatically invoked by the operating system. But being polymorphic, it is the override definitions that you provide in your code that actually get executed. This approach is used for the processing of "low-level" events in Qt. This approach is also used in wxWindows, a C++-based GUI toolkit for Unix and Windows, where virtual functions are invoked for processing the events generated by widgets. If an object needs to be informed of an event emitted by a widget, the object must be constructed from a class that extends the widget class and the class derivation must override certain virtual functions of the original widget class.

Yet other systems, Microsoft Foundation Classes (MFC) being a case in point, use macros and messages for event processing. Macros are used to link designated C++ methods to the various kinds of events that can be generated by the window system. The macros translate the events into "messages". Microsoft provides a graphical tool called IDE (for Interactive Design Environment) to help create the macros and messages.