The Life and Times of a Mouse Click

Preview:

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

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

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.

Recommended