05-830, User Interface
Software, Spring, 1997
Lecture 12, March 19,
Copyright © 1997 - Brad
Lecture . . .
"One of the most complex aspects of Xlib programming is
designing the event loop, which must take into account all of the possible
events that can occur in a window."
-- Nye & O'Reilly X Toolkit
Intrinsics Programming Manual, vol. 4, 1990, p. 241.
"The dispatching and handling of events is rather
-- Galaxy Reference Manual, v1.2, p. 20-5.
How Keyboard and Mouse Events are Handled
- Most window manager and toolkits use the same model
- Quite old and has problems
- Structures (records) composed of all information about events
- Edit the screen by editing the saved list
- Created by window manager, sent to a queue for each window
- X defines 33 different types of events:
- keymapNotify (change keymap)
- graphicsExpose (source of copy not available)
- noExpose (source of copy is available)
- propertyNotify (some property changed)
- visibilityNotify (become covered)
- circulateNotify (stacking order)
- configureNotify (resize or move)
- destroyNotify (was destroyed)
- gravityNotify (moved due to gravity)
- mapNotify (became visible)
- reparentNotify (in diff. window)
- unmapNotify (invisible)
- mappingNotify (keyboard mapping)
- selectionClear (for cut and paste)
- Except for selectionRequest, the *request events are only for window
- Windows specifically declare which events they want to receive using
- Reduces network traffic and unnecessary processing
- Event masks also used for other things: "pointerGrab"
- Toolkits (e.g., Motif) automatically handle expose and some other
events for the widgets.
- Structured graphics systems (e.g., Garnet) automatically handle many
of the events.
- Events (in X) are C-language union type of many event structures that
are all the same size but with different field names.
- Key and mouse events contain (at least):
- x position of the mouse
- y position of the mouse
- window of the mouse
- event type
- event code
- event modifiers
Waiting for Events
- Low-level routine that waits for event wants to be blocking
rather than polling for efficiency
- Calls specified routines when events arrive
- in Galaxy:
veventSetHandlerProc for a specify type
- Macintosh uses polling for mouse location
- Toolkits provide this internally, e.g.:
veventProcess() in Galaxy,
Am_Main_Event_Loop() in Amulet
- Can specify timeouts so notified after certain time if no events
- Can ask X to flush multiple motion events
- If not handled fast enough, get wierd lag
- Garnet tries to do extra flushing to avoid this
- Not an issue if polling for motion events
- Problem for polylines, gestures, etc.
- Events sent to the lowest level window containing the pointer.
- If event not selected with event-mask, then sent to the container window,
- Can't specify individual keys (get all keys and may have to explicitly
- So particular mouse key or keyboard key not hard-wired into
- Allows user customization and easier changes
- Supported in Motif by the resources mechanism
can be put
.Xdefaults, and then application deals with
doit, and user can change bindings.
- Keyboard translation is 2 step process in X:
- Hardware "keycodes" numbers mapped to "keysyms"
- "Keysyms" translated to events
- For double-clickings, Motif does translation, but not Xlib
- For non-widgets, have to do it yourself
- Always also get the single click events
- Race condition when copy from an area that might be
- Need to use graphicsExpose and noExpose events
Back to 05-830 main page