the life and times of a mouse click stuart a. hansen and timothy v. fossum university of wisconsin -...
TRANSCRIPT
The Life and Times of a Mouse Click
Stuart A. Hansen and Timothy V. Fossum
University of Wisconsin - Parkside
Image by Krash Concepts Engineering
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
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 ExamplesMouse ClickSmoke Alarm ActivatedDisk InterruptWater Level in Cooling Tank becomes too lowPower Outage that cascades across a large area
Examples of Event Driven SystemsDemocratic Governments
Digital WatchStop Light
TV remote controlCruise control system on your car
Graphical User InterfacesHardware InterruptsDatabase Triggers
Discrete/Hybrid SimulationMiddleware (e.g. CORBA)
Examples of Event Driven Programming Systems
GLUTX WindowsMFCJavaComponent Based Systems (events, persistence and visual presentation)
javax.swingJavaBeansVisual Basic
Event Driven Programs are Composed of Loosely Coupled Parts
Dynamic Relationship
Heterogeneous Relationship
Spatially Separated
Temporally Separated (Asynchronous)
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.
Heterogeneous Relationship
Sources, Handlers and Dispatching Mechanism may mix and match differently
• hardware• languages• software libraries
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
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
Definition of Event Driven Programming
Event Driven Programming is characterized by:
• Event Objects
• Event Sources
• Event Handlers
• Syntactic Glue
• Operational Semantics
Source
Event
HandlerSource createsEvent which isinterpreted by Handler
Software Engineering Event Driven Programs
Design
Programming
Testing
Design Techniques and Tools
Design Patterns
UML Models Activity Diagrams Sequence Diagrams State Charts
Design Patterns for Event Driven Programming
State PatternAllow 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 PatternEncapsulate 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.
Othershttp://csis.pace.edu/~bergin/patterns/event.html
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.
Statechart for a Traffic Lightborrowed from Binder 1999
Red
Green
Yellow
FlashingRed
Off On Cycling
Fault
FlashRedOn
RedOn
Reset
Lite Off
Sequence Diagram for an ATM Withdrawal
Interface Local Bank
Insert Card
Enter PINValidate PIN
Validate PIN
Money
AmountOK OK
Validate AmountValidate Amount
OKOK
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.
10 minute break
Coding Examples
http://cs.uwp.edu/Events/ITiCSE2001
Visual Basic Drawing Program
GLUT Drawing Program
Java Drawing Program
Event Programming with Java
Event Classesjava.awt.event:
ActionEvent, ComponentEvent, ContainerEvent, FocusEvent, InputEvent, InvocationEvent, KeyEvent, MouseEvent, PaintEvent, TextEvent, WindowEvent, . . .
Event SourcesMany AWT and Swing components are sources for input events
Listeners and Adapters facilitate the development of handlers
Event ListenersInterfaces that specify all the methods that are of interest for an event class
Event AdaptersImplement the listeners with empty methods. The application classes inherit from the
adapter and then implement just the methods of interest
Java draw example
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.
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)
Under the Hood
+Dispatching Mechanisms
+Hardware Interrupts
+X11 Events
+New Event Classes in Java
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)
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.
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
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
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
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
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)
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
10 minute break
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
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
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.
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
/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*/
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
Other mouse devices
Different ...
• bit layouts
• bytes per event
• raw data (e.g., Bus mouse sends quadrature signals - compare with WinModems)
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?
X11 eventsClient/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
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
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);
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;
...
}
}
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;
Event propagation
o Events propagate up the window hierarchy
o Events do not propagate beyond the selecting window
X11 window geometry
Window origin is in upper-left hand corner
o Positive x values are to right
o Positive y values are down
o X11 server translates raw mouse dx,dy values
o Incorrect assumptions about mouse protocol may result in bizarre behavior!
Higher-level libraries may use different geometries
(e.g., OpenGL)
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
Defining New Event Types in Java
One interface and three classes:
Event object classInherit from java.awt.event
Event source classResponsible for creating events and calling all appropriate handlers
Event handlers Event Listener Interface and Event Handler class
Egg timer example
Egg Timer Exercises
• Modify the code so that there are two handlers.• What behavior do you expect?
• Modify the code so that there are two timers. • Set the time on the second timer to 10 seconds.• Register both handlers with the second timer.
• Define a new repeatable handler class that handles the event by creating a new 1-second timer, registering itself with the timer, and starting the timer.
Experts' Exercise
Create a delayed drawing program combining the drawing and timer programs:
• the program should respond to the same events as the original program, but all drawing should take place one second after the mouse motion event
• all other events (clearing, selecting colors, etc.) should take place with minimal delays
What would Dijkstra say?
". . . our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible."
from "Go to Statement Considered Harmful" CACM, March 1968
Wrap-up
• What have you learned?• What more would you like to learn?• What topics were too sketchy?• What details should be left out?• How could you use this material in your
curriculum?• does it have a place?• if so, where?
Resources
Tutorial URL: http://cs.uwp.edu/Events/SIGCSE2001
Bach, Maurice J., The Design of the UNIX Operating System, Prentice-Hall, 1968.Binder, Robert V., Testing Object-Oriented Systems: Models,Patterns, and Tools, Addison-Wesley,
1999.Comer, D., and Fossum, T., Operating System Design, the Xinu Approach, PC Edition, Prentice-Hall,
1988.Deitel & Deitel, Java: How to Program, 3rd ed., Prentice Hall, 1999.Dijkstra, Edsger W., Go To Considered Harmful, CACM, March 1968 (reprinted in CACM, October
1995).Ekedahl, Michael V., Developing Applications with Microsoft Visual Basic: Advanced Topics, Course
Technology, 1999.Englander, Robert, Developing Java Beans, O'Reilly, 1997.Feuer, Alan R., MFC Programming, Addison-Wesley, 1997.Fowler, Martin, UML Distilled, 2nd ed., Addison-Wesley, 1999.Gamma, Erich, et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-
Wesley, 1995.Java Language Team, About Microsoft's "Delgates", Sun Microsystems, 2000.Microsoft Corporation, The Truth about Delegates, Microsoft White Paper, September 1, 1998.