The Life and Times of a Mouse Click

1. The Life and Times of a Mouse Click Stuart A. Hansen and Timothy V. Fossum University of Wisconsin - Parkside Image by Krash Concepts Engineering

2. Overview of Workshop • Events and Event Driven Programming • Software Engineering Event Driven System • Examples from UML, GLUT, Visual Basic and Java • Under the Hood • Interrupts and OS events • X11 and Java • Wrap-up

3. Definition of Event An event is a transition in the control state of a system. It may have an action (side effect) associated with it. Event Examples Mouse Click Smoke Alarm Activated Disk Interrupt Water Level in Cooling Tank becomes too low Power Outage that cascades across a large area

4. Examples of Event Driven Systems • Democratic Governments • Digital Watch • Stop Light • TV remote control • Cruise control system on your car • Graphical User Interfaces • Hardware Interrupts • Database Triggers • Discrete/Hybrid Simulation • Middleware (e.g. CORBA)

5. Examples of Event Driven Programming Systems • GLUT • X Windows • MFC • Java • Component Based Systems • (events, persistence and visual presentation) • javax.swing • JavaBeans • Visual Basic

6. Event Driven Programs are Composed of Loosely Coupled Parts • Dynamic Relationship • Heterogeneous Relationship • Spatially Separated • Temporally Separated (Asynchronous)

7. Dynamic Relationship • Binding Sources and Handlers is done at run time. • The binding may change during the course of execution. • Component systems often distinguish "design time" from "run time", even though both are part of executing the system.

8. Heterogeneous Relationship • Sources, Handlers and Dispatching Mechanism may mix and match differently • hardware • languages • software libraries

9. Spatially Separated • Sources, Handlers and Dispatching Mechanism may exist: • in different files • on different machines • at different conceptual levels • hardware and OS • OS and Windowing System • Windowing System and Application

10. Temporally Separated • Usually small and possibly indeterminate time between event occurring and it being handled • Source not necessarily blocking • Handlers' activities may change association of Sources and Handlers dynamically

11. Definition of Event Driven Programming Event Driven Programming is characterized by: • Event Objects • Event Sources • Event Handlers • Syntactic Glue • Operational Semantics Event Handler Source Source creates Event which is interpreted by Handler

12. Software Engineering Event Driven Programs • Design • Programming • Testing

13. Design Techniques and Tools • Design Patterns • UML Models • Activity Diagrams • Sequence Diagrams • State Charts

14. Design Patterns for Event Driven Programming State Pattern Allow an object to alter its behavior when its internal state changes. Introduce an abstract class named State and use different concrete implementations to capture behavior. Command Pattern Encapsulate a request as an object, thereby letting you parameterize clients with different requests. e.g., Menus can easily be implemented by making each menu choice an instance of a MenuItem class. Others http://csis.pace.edu/~bergin/patterns/event.html

15. UML Models State Charts = Generalization of a State Machine Sequence Diagrams = Model of all the Events and Objects involved in carrying out an Interaction with the system.

16. Off Red Flashing Red Green Yellow Statechart for a Traffic Lightborrowed from Binder 1999 On Cycling Reset RedOn Lite Off Fault FlashRedOn

17. Sequence Diagram for an ATM Withdrawal Interface Bank Local Insert Card Enter PIN Validate PIN Validate PIN OK OK Amount Validate Amount Validate Amount OK OK Money

18. Sequence Diagram Exercises Develop a sequence diagram for initiating use of the cruise control system of your car. List at least three exceptions that might occur while using the system.

19. 10 minute break

20. Coding Examples • http://cs.uwp.edu/Events/ITiCSE2001 • Visual Basic Drawing Program • GLUT Drawing Program • Java Drawing Program

21. Event Programming with Java • Event Classes • java.awt.event: • ActionEvent, ComponentEvent, ContainerEvent, FocusEvent, InputEvent, InvocationEvent, KeyEvent, MouseEvent, PaintEvent, TextEvent, WindowEvent, . . . • Event Sources • Many AWT and Swing components are sources for input events • Listeners and Adapters facilitate the development of handlers • Event Listeners • Interfaces that specify all the methods that are of interest for an event class • Event Adapters • Implement the listeners with empty methods. The application classes inherit from the adapter and then implement just the methods of interest

22. Java draw example

23. Java Draw Exercises Add right mouse button code to draw in blue. Move the color attribute to the Circle class to fix the repaint in one color bug. Add a menu option to clear the window.

24. Testing State Machines The following types of faults may all occur in state machines: • A missing or incorrect event • A missing or incorrect action (side effect) • An extra, missing, or corrupt state • A sneak path (a message accepted that shouldn't be) • An illegal message failure • A missing or incorrect transition • A trap door (the implementation accepts undefined msgs)

25. Under the Hood +Dispatching Mechanisms +Hardware Interrupts +X11 Events +New Event Classes in Java

26. Push vs. Pull Push: event dispatch takes place in the execution thread of the source object Pull: event dispatch takes place in the execution thread of the handler - normally through polling Post office example - two scenarios: • Post office delivers letter to addressee (push) • Post office puts letter in PO box; addressee checks PO box periodically to get letters (pull)

27. Push Source must know what handlers to call when event occurs (handler registers with source) Source normally blocks until handler returns Cascading events may result in source executing many nested handlers Event handling may change data structures at run-time - need to clone dispatch vectors, e.g.

28. Pull Events are queued by the source for later inspection by handler Events may be lost if handler cannot process events as fast as they arrive (queue becomes full) Handler may receive events it does not want Handler is typically written as an "event loop" that blocks when there are no events in queue

29. Event dispatch masking How does a handler ignore ("mask") unwanted events? • ask source to deliver only particular events, or • receive all events but only act upon particular ones An intermediate object (adapter) can be given the task of receiving events and dispatching particular events to appropriate handlers

30. Adapters Source can push events to adapter which manages the details of further event dispatch Handler can register with adapter to identify which events it wants to receive Adapter can be given a thread of control so source does not block

31. Interrupt Events Event: Processor interrupt line is asserted Source: Hardware device Handler: Operating system (OS) Dispatch: OS loads interrupt vector with address of Interrupt Service Routine (ISR); Upon event, device identifies itself via its interrupt number; OS steals CPU resources from current process to execute ISR

32. Interrupt Service Routines ... must not block! will normally generate "higher level" OS events must guarantee that the OS is maintained in a consistent state (compare to synchronized Java methods)

33. Higher-Level OS Events Xinu (Comer/Fossum) event handling • ISRs post events to the kernel event queue • Interrupts disabled during queue manipulation • Event examples: • send a message to a process • signal a semaphore • User-level process takes events from queue and handles them (e.g., send or signal) • Decouples ISR from system call interface

34. 10 minute break

35. PS/2 Mouse • Serial device - typically 1200 baud • Interrupt number 12 (e.g.) • Generates a 3-byte sequence for every mouse movement and/or button click

36. PS/2 Mouse Data Format d7 d6 d5 d4 d3 d2 d1 d0 1: yv xv ys xs 1 0 R L 2: x7 x6 x5 x4 x3 x2 x1 x0 3: y7 y6 y5 y4 y3 y2 y1 y0 xs,ys = dx,dy movement sign R=right button; L=left button x7-x0=dx movement bits y7-y0=dy movement bits

37. PS/2 mouse semantics • dx and dy represent relative movement • Right mouse movement yields postive dx values • Up mouse movement yields positive dy values • dx and dy values are in 2's complement • a mouse movement and button click can result in a single mouse event (3-byte transfer) • even fast mouse movements generally result in small values of dx and dy.

38. OS-level mouse events Event: byte received from mouse by OS via ISR Source: OS kernel Handler: Application process Glue: OS installs ISR address in interrupt vector (plus some hardware glue) Dispatch: Application connects to device via open call, reads from device and blocks until a byte is available; OS unblocks application when byte is available. Three bytes read per event

39. /dev/mouse The Linux mouse device is/dev/mouse Symbolically linked to /dev/psaux for the PS/2 mouse /dev/mouse is a character device - a process can open and read from the device a character at a time: mdev = open("/dev/mouse"); read(mdev, &c, 1); /*1st of 3*/

40. Code example • Open /dev/mouse • Read an interpret 3-byte sequences in a loop (pull!) - read will block until a byte is available • Sample output: left=0 right=0 dx=0 dy=1 left=1 right=0 dx=0 dy=-1 left=0 right=1 dx=0 dy=0 left=1 right=0 dx=4 dy=-2

41. Other mouse devices Different ... • bit layouts • bytes per event • raw data (e.g., Bus mouse sends quadrature signals - compare with WinModems)

42. Mouse event semantics What constitutes a double click? Should mouse clicks and mouse movements be considered separate events? Should the OS provide a generic mouse device interface?

43. X11 events Client/server model • an X11 client is a process running on a host • an X11 server is a display (screen, keyboard, mouse) that provides a user interface

44. X11 sources and handlers • The server is a source of mouse, keyboard, and window change events • The client is a handler that pulls events from its event queue • Each client process has its own event queue

45. X11 Event types (Xlib C interface) A client registers with the server the event types it wants to receive Sample event types: • ButtonPress (mouse click) • KeyPress • PointerMotion XselectInput(d,w,ButtonPressMask);

46. Client event loop XEvent Event; /* large enough for all */ while(1) { XNextEvent(d, &Event); /*blocks*/ switch(Event.type) { case ButtonPress: /*respond to button press*/ break; ... } }

47. Xlib ButtonPress event structure typedef struct { int type; /*event type = 4*/ ... Time time; /*ms when occurred*/ int x,y; /*window coords*/ int x_root, y_root; /*root coords*/ ... unsigned int button; /*the button*/ ... } XButtonPressedEvent;

48. Event propagation • Events propagate up the window hierarchy • Events do not propagate beyond the selecting window

49. X11 window geometry Window origin is in upper-left hand corner • Positive x values are to right • Positive y values are down • X11 server translates raw mouse dx,dy values • Incorrect assumptions about mouse protocol may result in bizarre behavior! Higher-level libraries may use different geometries (e.g., OpenGL)

50. Double clicks Xlib does not have a double click button event! A "double click" can be detected using the Time field of the XButtonPressedEvent structure Higher-level libraries, such as Xt, may define double click semantics, otherwise... ...it's up to the application program