05-830, User Interface Software, Spring, 1998
Lecture 12,   March 16, 1998
Copyright © 1998 - Brad Myers

Input Models

"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 complicated."
-- 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

Event Records

• 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:
  1. buttonPress
  2. buttonRelease
  3. keyPress
  4. keyRelease
  5. motionNotify
  6. enterNotify
  7. leaveNotify
  8. focusIn
  9. focusOut
  10. keymapNotify (change keymap)
  11. expose
  12. graphicsExpose (source of copy not available)
  13. noExpose (source of copy is available)
  14. colormapNotify
  15. propertyNotify (some property changed)
  16. visibilityNotify (become covered)
  17. resizeRequest
  18. circulateNotify (stacking order)
  19. configureNotify (resize or move)
  20. destroyNotify (was destroyed)
  21. gravityNotify (moved due to gravity)
  22. mapNotify (became visible)
  23. createNotify
  24. reparentNotify (in diff. window)
  25. unmapNotify (invisible)
  26. circulateRequest
  27. configureRequest
  28. mapRequest
  29. mappingNotify (keyboard mapping)
  30. clientMessage
  31. selectionClear (for cut and paste)
  32. selectionNotify
  33. selectionRequest
• Except for selectionRequest, the *request events are only for window managers
• Windows specifically declare which events they want to receive using event masks
  • 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):
  1. x position of the mouse
  2. y position of the mouse
  3. window of the mouse
  4. event type
  5. event code
  6. event modifiers
  7. timestamp

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 of event
  • Macintosh uses polling for mouse location
• Toolkits provide this internally, e.g.: XtAppMainLoop(...) 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.

Propagation

• Events sent to the lowest level window containing the pointer.
• If event not selected with event-mask, then sent to the container window, etc.
• Can't specify individual keys (get all keys and may have to explicitly resend events)

Translation Tables

• So particular mouse key or keyboard key not hard-wired into application.
  • Allows user customization and easier changes
• Supported in Motif by the resources mechanism
  • e.g. Shift<Btn1Down>: doit()
    can be put in .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

Scrolling

• Race condition when copy from an area that might be covered
  
• Need to use graphicsExpose and noExpose events

Back to 05-830 main page