1. Gary MarsdenSlide 1University of Cape Town Human-Computer Interaction - 3 Programmer Support Gary Marsden ( gaz@cs.uct.ac.za ) July 2002

2. Gary MarsdenSlide 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

3. Gary MarsdenSlide 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

4. Gary MarsdenSlide 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 prone  For the rest of the lecture we will look at higher level abstractions for programming interfaces

5. Gary MarsdenSlide 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

6. Gary MarsdenSlide 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)

7. Gary MarsdenSlide 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!

8. Gary MarsdenSlide 8University of Cape Town Overview

9. Gary MarsdenSlide 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

10. Gary MarsdenSlide 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

11. Gary MarsdenSlide 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

12. Gary MarsdenSlide 12University of Cape Town Read-Evaluation overview

13. Gary MarsdenSlide 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

14. Gary MarsdenSlide 14University of Cape Town Notifier Overview

15. Gary MarsdenSlide 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”

16. Gary MarsdenSlide 16University of Cape Town Flavours  Toolkits come in many flavours

17. Gary MarsdenSlide 17University of Cape Town Toolkit Programming  You can glue the components together to form meta-widgets, then glue these to form whole applications  Very OO  You get consistency across applications –Look and feel  Often come with style guides –Mac thought police  Account for 50% of code in most applications

18. Gary MarsdenSlide 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

19. Gary MarsdenSlide 19University of Cape Town Future Developments  Grammar Notations - UIML  State transition diagrams  Event languages  Declarative Languages  Constraints  Graphical Programming

20. Gary MarsdenSlide 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