Gary Marsden Slide 1University of Cape Town

Human-Computer Interaction - 3

Programmer Support

Gary Marsden(gaz@cs.uct.ac.za)

July 2002

Gary Marsden Slide 2University of Cape Town

Unit Objectives

We shall cover– Abstract terminals– Toolkits– UIMS

Rationale:– About 50% of coding effort in an application is

related to the interface– WIMP interfaces are the most common, it is

therefore essential to understand the programming paradigms behind these

Gary Marsden Slide 3University of Cape Town

In the beginning...

Programming languages were based on – Input - process - output

This is clearly useless as an interactive computing paradigm

Therefore old languages were upgraded with toolkits and APIs to make them cope with WIMP interfaces

As WIMPs standardised, so did the extensions

Gary Marsden Slide 4University of Cape Town

Interactive Extension

At the most basic level a language must– Respond to some event (mouse click, etc.)– Draw things on the screen

This is too low level and error proneFor the rest of the lecture we will look at

higher level abstractions for programming interfaces

Gary Marsden Slide 5University of Cape Town

Key Elements

Hardware independence is essential– Abstract keyboard, screen & pointing device

Therefore programmer works to an abstract terminal– Easier and more portable– Device manufacturers build drivers to work to

abstract specification

Each window system has its own ‘imaging model’– PDF, GKS, PHIGS or just pixels

Gary Marsden Slide 6University of Cape Town

Interactivity

Interactive interfaces require concurrency– This is hard to program

Windows systems support several instantiations of the abstract terminal

Concurrency issues handled by window system

System also provides active screen regions for each application (i.e. a window)

Gary Marsden Slide 7University of Cape Town

Implementing Windows

One approach is to put the window management code in the operating system (as it deals with resource allocation anyway)– Ties applications to OS

More flexible to move management to a separate application– Generic across all OSs– “Client-server” architecture– But slow!

Gary Marsden Slide 8University of Cape Town

Overview

Gary Marsden Slide 9University of Cape Town

Reality

Most window systems have evolved and are part separated, part integrated

A common example of a client-server system is X-11 from MIT

Gary Marsden Slide 10University of Cape Town

X11

Based on a network protocol (X) Each client runs a local abstract terminal The server

– Does permissions for single/multi application windows– Interprets screen requests from clients– Routes user events to correct client– Minimises traffic using ID numbers

The client– Runs a window manager– Managers can be wildly different

X11 - nice but slow and hard to use

Gary Marsden Slide 11University of Cape Town

Application Programming

We need to look at how the client is programmed– I doubt you will write a window manager

Read-evaluation is one paradigm (Mac)– Server is responsible for routing events– Client is sent event ‘record’ containing details

• E.g. right mouse button clicked at 100,154

– Client has complete control of processing– Programmer has to code event responses for

every event– Basically a continuous loop

Gary Marsden Slide 12University of Cape Town

Read-Evaluation overview

Gary Marsden Slide 13University of Cape Town

Notification Based

In a notification based system, applications register the events they are interested in

Centralised notifier receives all events and dispatches appropriately

Applications use callback procedures which are associated with each event

Control is passed to the callback, which passes it back to the notifier on completion

Gary Marsden Slide 14University of Cape Town

Notifier Overview

Gary Marsden Slide 15University of Cape Town

Toolkits

A window systems is fine for coping with events and screens, but still low-level

There are issues with input & output integration

We want to program with interaction objects– “Widgets” which live in families called “Toolkits”

Gary Marsden Slide 16University of Cape Town

Flavours

Toolkits come in many flavours

Gary Marsden Slide 17University of Cape Town

Toolkit Programming

You can glue the components together to form meta-widgets, then glue these to form whole applications

Very OOYou get consistency across applications

– Look and feel

Often come with style guides– Mac thought police

Account for 50% of code in most applications

Gary Marsden Slide 18University of Cape Town

UIMS

User Interface Management Systems sit on top of toolkits

Idea is to separate application semantics from interface– MVC in smalltalk

For my PhD, I basically argued against this approach– Got away with it– HyperCard is king of integrating semantics and

interface

Gary Marsden Slide 19University of Cape Town

Future Developments

Grammar Notations - UIMLState transition diagramsEvent languagesDeclarative LanguagesConstraintsGraphical Programming

Gary Marsden Slide 20University of Cape Town

Summary

You should now have a good idea of:– Abstractions for graphics systems– The role of abstract terminals– Event based programming– Toolkits– UIMS