Event-Driven Programming - Essentials of Interactive Computer Graphics - page 19

is also an example of a GUI element, where a few rectangles are used to represent
the title bar and work area with a few surrounding lines representing the window
borders. Typical applications first create the main window GUI element and then
place other GUI elements at strategic locations inside the application's window to
associate semantic meanings with those locations. For example, the ball-shooting
program in Figure I.2 has six GUI elements:
1. Container main window;
2. Drawing area for the balls;
3. Two slider bars;
4. Quit button;
5. Status bar.
As we will see in Tutorial 2.8, in general, it is possible to place a window GUI el-
ement within another window GUI element. As the complexity of our application
increases, this is a convenient and powerful way to organize the large number of
GUI elements involved.
After receiving hardware device state change information from the window
manager, the GUI API translates this information into events and forwards the
events to the currently active GUI element. For example, a mouse click on an in-
focus “button GUI element” is translated into a “button-pressed event,” whereas
a mouse click over a “slider bar GUI element” is translated into a “slider bar
position event” with an appropriate scroll values.
Sometimes it is not appropriate/meaningul for the GUI API to translate and
forward hardware state change information. For example, a user performs a
mouse click over the status bar area of Figure I.2. Because the status bar is an
output-only GUI element, it is not capable of receiving any input events. In cases
like this, the GUI API typically allows the application to choose between dis-
carding the event or translating and forwarding the event to the GUI element that
contains the in-focus element. In this case, the main application container window
would receive the mouse click event.
In practice, events have many triggering origins. For example, the user can
trigger input events; the window manager can decide to enter screensaver mode
and trigger events to inform all applications; or the OS can detect hardware ab-
normality and trigger events via the window manager. Ultimately, relevant events
will be sent to our applications. From within our applications, it can be impos-
sible to determine the true origin of an event. For example, a system hardware
failure may result in the window manager sending a “save and quit” event to our