Transcript The Life and Times of a Mouse Click

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 Examples
Mouse Click
Smoke Alarm Activated
Disk Interrupt
Water Level in Cooling Tank becomes too low
Power Outage that cascades across a large area
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)
Examples of Event Driven
Programming Systems
GLUT
X Windows
MFC
Java
Component Based Systems
(events, persistence and visual presentation)
javax.swing
JavaBeans
Visual 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
•
Event Sources
•
Event Handlers
•
Syntactic Glue
•
Operational Semantics
Source
Source creates
Event which is
interpreted by
Handler
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 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
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 Light
borrowed from Binder 1999
Off
Lite Off
Reset
Fault
On
Cycling
Red
Green
Yellow
RedOn
Flashing
Red
FlashRedOn
Sequence Diagram for an ATM
Withdrawal
Interface
Bank
Local
Insert Card
Enter PIN
Validate PIN
Validate PIN
OK
OK
Amount
Validate Amount
OK
Money
Validate Amount
OK
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 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
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 runtime - 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 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
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
o
Events propagate up the window hierarchy
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 class
Inherit from java.awt.event
Event source class
Responsible 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, AddisonWesley, 1995.
Java Language Team, About Microsoft's "Delgates", Sun Microsystems, 2000.
Microsoft Corporation, The Truth about Delegates, Microsoft White Paper, September 1, 1998.