Most current state-of-the-art applications are event-driven, for example all applications written in X11 or GEM. Every time something happens (e.g. a key is pressed or the mouse is moved) an event is generated. An event is characterized by a unique identity code and a data structure containing information about this event. Usually, the system maintains a queue of events, in order to ensure that all events are being handled, independent of CPU usage fluctuations. This means that ``immediate response but probability of missed events'' is traded off against ``possibly delayed response but all events are handled''. There exist standard procedures for getting an event from the event queue. The application is responsible for performing some action that corresponds with the event. As an example, each application is responsible for its screen content integrity. Applications send eachother events in case they modify the screen content. The receiving application must then decide whether a portion of the screen must be ``repainted''.
The effect on the application is that long calculations are forbidden, because if events are not processed for a long time, the user cannot do anything but wait. Events such as the Ctrl-C or ESCAPE-key cannot be used anymore for interrupting the calculation process, unless they are purposely processed inside the calculation loop. This is not a good way of programming, while the application has to take care of all possible events.
In MS-Windows, a slightly different approach is taken. Events are called 'messages', and they are used for all inter-application communications. Because does not use MS-Windows, this is not considered further.
Two levels of event-handling can be considered. At a lower level, (GEM, X11) events are generated by the hardware, together with some low-level information. In Motif and Tcl/Tk, a layer is put on top of this, releasing the application from a lot of house-keeping chores.
Esprit Project 8579/MIAMI (Schomaker et al., '95)