Department of Computer and Information Science,
School of Science, IUPUI
Dale Roberts, Lecturer
Computer Science, IUPUI
E-mail: droberts@cs.iupui.edu
Dale Roberts

Application Level Programming
Uses widget sets and style guidelines to create application GUIs. Examples: Motif, MFC, Qt, GTK, etc.
Graphical Systems Programmer
Person who implements the widget sets and windowing systems above
Dale Roberts

By now, you have been exposed to two programming paradigms:
Functional Programming
Object-oriented Programming
Can you explain their differences in terms of:
How to decompose a problem?
How to express control?
Dale Roberts

How do to decompose a problem?
Top-down functional decomposition approach.
Step-wise refinement
Successive versions of algorithms written in pseudo-code
Problem is divided into smaller subproblems
Each “decomposition” is a function call.
Keep decomposing until functions are close enough to target language to code.
How do you express control?
Each step is a function call.
Flow of control statements are used within functions
Dale Roberts

How do to decompose a problem?
Bottom-up building block approach.
Identify objects needed to solve the problem.
Create an Abstract Data Type implemented with objects
Identify how values are represented in private data members.
Define operations that act upon values as public member functions.
Encapsulate implementation details within the class.
How do you express control?
Use UML to define relationships between classes.
Flow-of-control between classes is relatively unstructured.
Must still define a client that uses classes to solve a problem.
Client is usually responsible for user-interaction, not classes.
Stratifies application into presentation, processing, and data layers.
Dale Roberts

Event-driven programming is the standard approach to creating graphical user interfaces
(GUIs)
An event-driven program is object-oriented
Not a new programming “paradigm”
Object-oriented programming was originally development to implement graphical objects within GUI operating systems
However, top-level control is expressed differently
The user is the top-level loop
Think of Word, or a game program
Every action in your program is a reaction to the user
Decompose program in terms of “what will I do if the user does…”
User inaction may trigger background actions (e.g. games)
Dale Roberts

Polling
Repeatedly read input devices in an infinite loop
Interrupt-driven
Hardware-triggered context-switching in response to userevents
Event-driven
Explicit event waiting
Call-back functions (i.e. signals) in response to user events
Qt uses event-driven processing.
Dale Roberts

Interaction is governed by a simple loop:
Loop forever:
{ read input respond to input
}
What limitations does this have?
Does it have any advantages?
Dale Roberts

3.
4.
5.
1.
2.
Enable device, then proceed with “background” processing until an interrupt is received, at which point
Save state (context-switch)
Respond to input
Restore state and go to step #2.
What advantages/disadvantages does this have?
Dale Roberts

Interaction is once again governed by a loop:
Loop forever:
{ if (event) then else respond do (one unit of) background processing or go to sleep (for one unit)
}
Dale Roberts

All major GUI packages (Motif, MGC, Qt, GTK,
Java AWT, …) are event driven.
Why?
More portable than interrupt-driven.
At the expense of what?
More efficient than polling most do have polling commands
Can rely on operating system to do time-slicing context-switching is very hardware/operating system specific.
Dale Roberts

Any event-driven graphics package has devices that can signal events
In old standards, this was limited to hardware devices
In newer packages (e.g. Qt), any widget can signal events; the (hardware) mouse is the same as a
(software) slider or button.
Generally, the event tells you
Which device/widget signaled the event
Some “measure” giving the new state
E.g., whether a mouse button was depressed or released
Warning: old systems tend to use the term “events” while newer systems may call them signals (e.g. Qt)
Dale Roberts

A call-back function is an application-specific function called in response to an event
In Qt, these are called “slots”, but this term is unique to Qt
Generally, the “measure” of the event is passed as an argument
The main loop of a GUI program is:
Wait for an event
Call the associated call-back function
Return to the top of the loop
Dale Roberts

Loop forever:
{ if (input) then { find out which application receives the event; invoke the callback function;
} else select one application with a background callback function; invoke background callback;
}
Dale Roberts

The process of selecting which window (or application) an event belongs to is called pick correlation
Pick correlation is usually object-oriented:
Every window knows where its children are children send parents a message when they move, etc.
The top-level window assigns events to children
Child processes may handle the event through a call-back; or ask their children “is this yours”?
Dale Roberts

Modern widget packages (like Qt) hide the main loop from the programmer.
Programmers declare signals i.e. what events to respond to
Programmers define slots i.e. how to respond to events
Programmers connect signals to slots
The main loop (wait for signal / call slot / loop) is part of the widget package
Programmers call the main loop, but can’t alter it, other than through signals and slots
Dale Roberts

int main (int argc, char* argv[])
{
QApplication app( argc, argv);
GUI main( &app, &state) app.setMainWidget( &main); main.Show(); return app.exec();
}
Where’s the program? GUI is a widget. The GUI class defines signals and slots, and the GUI’s constructor connection them…
Dale Roberts

The objects in an object-oriented GUI are called
widgets.
Every widget:
Knows its location (for pick correlation)
Knows whether of not its visible
Knows how to resize itself
Knows how to redraw itself
Knows its “children” widgets (if it’s a container)
Has call-back functions (slots) for handling events
(signals)
Every window is a widget
Not all widgets are windows
Dale Roberts

Text editing windows (canvases)
Push buttons
Menus
Sliders
Radio buttons
LED displays
Borders
Dale Roberts

Every application has a top-level widget
In Qt, the top-level widget is called QApplication
QApplication implements the main signal/slot loop
QApplication is a widget but not a window
QApplication in turn has a single top-level window
Inside is a hierarchy of lesser widgets: frames, etc., for grouping and position widgets low-level widgets:buttons, pop-up menus, etc.
Call-back functions (signals) are attached to implement responded to user actions
Events are passed by the OS to the application’s top-level widget.
Dale Roberts

Some of the slides were originally written by J. Ross Beveridge, updated by Dale
Roberts.
Dale Roberts