|
|
Data from graphics input devices like mice is received by the application in the form of ``events''. An event represents a movement or action on the part of the graphics input device. For example, moving a mouse generates a series of signals from the mouse that are interpreted as discrete events. An ``up'' motion of the mouse is interpreted as an ``up'' event. Events are accumulated in, and read from, an ``event queue''. Mouse support is provided by a series of utilities and system services collectively known as the event manager. The event manager consists of kernel functionality to read and manage graphic input device data, an event driver, and an Application Programming Interface.
The event manager API allows applications software to be portable to systems with different event devices, such as a different brand of mouse or a mouse attached to a different port. The interface provides routines for opening and accessing an event queue. A variety of graphics input devices, such as mice, bitpads or the keyboard, may be used with the event driver. Note, however, that the event manager API is not part of any current industry standards so may not be portable to other UNIX platforms.
Speed is of top priority in graphics applications, so the event driver and the system routines are optimized for speed of access. Applications written with the event manager API should also be optimized for speed.
Applications which use the Event Manager API, and which run under SCOterm windows, will not read events from the event queue unless SCOterm allows it. This feature can be toggled on and off by pressing <Ctrl><Alt><Bksp>; when off, mouse movements, button clicks and other events will be interpeted by SCOterm and not passed on to the application. When active, the reverse occurs; events are placed in the event queue and are not interpreted by SCOterm. Furthermore the pointer will disappear and focus will remain in the SCOterm window, until the feature is toggled off.