1. QT – Introduction C++ GUI Programming with Qt 4
Blanchette and Summerfield, Ch. 1
Miller, 2004

2. Overview
User interface (UI) software architectures for hci (and graphics)
About UI programming systems, or toolkits
View hierarchy, stroke drawing, pixel model, input handling, widgets
They are all alike and all different
A software layer
Qt, as software layer “above” Windows api, provides a different view
Makes most day to day things easier
“Slots” and “signals” for event handling and inter-dialog communication
Widget styles
Window system native, or common across platforms
Qt ide and resources

3. Familiar Systems …
So, the subject(s) of this course – human computer interaction
Computer system, human, software, hardware, programming, models, …
Also, will be concerned with how to program display and interaction mechanisms common to user interface implementation
Even learn some things about the human
Cognition, performance, …

4. Overview of Interactive Systems Focus on Programming
Humans (open system) interact with
computers (closed system) primarily through
displays - and input devices
Now, we will be learning the “craft” of programming for interactive systems

5. Overview of Interactive Systems Focus on Programming
Humans (open system) interact with
computers (closed system) primarily through
displays - and input devices
Now, we will be learning the “craft” of programming for interactive systems

6. Overview of Interactive Systems Focus on Programming
Humans (open system) interact with computers (closed system) primarily through displays - and input devices
Now, we will be learning the “craft” of programming for interactive systems
Other courses focus on programming the graphics elements
… but learning interaction programming is a big part
Historically, study of interactive systems started in computer graphics community!

7. Software Architecture Window systems and graphics systems
Window system controls/manages window creation, appearance, messages (event queue), etc.
Has own native API for programming – Qt is a layer “above” that (more later)
Graphics system controls graphics display hardware
Mainly OpenGL – GL and its utilities, GLU
GLUT, Qt
GLU GL
GLX, AGL or WGL
X, MS Windows, Mac os
software and/or hardware
application program
OpenGL Motif
widget or similar
graphics
system
window
system

8. Software Architecture Window systems and graphics systems
GLUT (& now Qt) - layer for access to both window & graphics systems
GLUT uses GLU and GL for graphics
Controls operating and window systems primarily through GLX, AGL, WGL
Callback functions are means GLUT uses to “shield programmer from intricacies of direct event loop programming”
GLUT, Qt
GLU GL
GLX, AGL or WGL
X, Win32, Mac O/S
software and/or hardware
application program
OpenGL Motif
widget or similar
window
system
graphics
system

9. Software Architecture Window systems and graphics systems
Qt also provides access to both window and graphics system
Widely used and robust, e.g., Google Earth
Many more widgets
Tradeoff:
Flexibility (not all window system calls available)
GLUT, Qt
GLU GL
GLX, AGL or WGL
X, Win32, Mac O/S
software and/or hardware
application program
OpenGL Motif
widget or similar
window
system
graphics
system

10. Software Arch., Window System “The familiar” – No Graphics API Use
“Application Progs”
E.g., student programs
MS Excel, etc.
Tools: UI Program.
MFC, Swing,
Qt (widget toolkit and more)
Window system API
MS windows
X tools
Graphics API
OpenGl (no win sys func)
DirectX
CPU
GPU
Graphics Processing Unit

11. Software Arch., Graphics – 1 “Simple” Use of Graphics API
“Application Progs”
E.g., student programs
MS Excel, etc.
Window system API
MS windows
X tools
GLUT
OpenGL Utility Toolkit
Graphics API
OpenGl (no win sys func)
DirectX
CPU
GPU
Graphics Processing Unit

12. Software Arch., Graphics – 2 Tool/package Use of Graphics API
“Application Progs”
E.g., student programs
MS Excel, etc.
Tools: Vis. Program.
VTK
s3s
Window system API
MS windows
X tools
Graphics API
OpenGl (no win sys func)
DirectX
CPU
GPU
Graphics Processing Unit

13. Software Arch., Graphics – 3 Graphics API Use
“Application Progs”
E.g., student programs
MS Excel, etc.
Tools: Vis. Program.
VTK
Window system API
MS windows
X tools
GLUT
OpenGL Utility Toolkit
Graphics API
OpenGl (no win sys func)
DirectX
CPU
GPU
Graphics Processing Unit

14. Software Architecture, All
“Application Progs”
E.g., student programs
MS Excel, etc.
Tools: UI Program.
MFC, Swing,
Qt (widget toolkit and more)
Tools: Vis. Program.
VTK
Tools: Graphic
Maya, 3ds
Window system API
MS windows
X tools
GLUT
OpenGL Utility Toolkit
Graphics API
OpenGl (no win sys func)
DirectX
CPU
GPU
Graphics Processing Unit

15. Challenges in Learning “Craft” of User Interface Programming
Challenges in part arise from user interface programming in general:
~ 50+% of applications code is user interface code!
Event driven software architectures
Simple complexity
Real-time requirements
Output 60 times/sec, keep up with mouse/touch tracking - Multimedia: video, animations, sound, …
Need for robustness
No crashing on any input
Helpful error messages, graceful recovery
Allow abort and undo
Lower testability
E.g, difficult to test direct manipulation, same state
Complexity of tools and API

16. User Interface Programming Natively, Event Driven Software Architectures
“regular programming” is (sort of) “top to bottom”: …
a = 1 …
Scanf (b …)
Printf (a …)
“regular programming” typically has i/o through the screen display device and keyboard input device
It’s control flow is top-to-bottom (sequential) with iteration, decision, and function calls
It is not set up to handle asynchronous input and output
Is not “event-driven”, as we will see
i.e., not use an event driven architecture

17. User Interface Programming Window Systems
In fact, there is are software layers (“window system”, etc.) between the input and output of “regular” programming
Accessing these intermediate layers, e.g., window system, allows programming of elements otherwise inaccessable
Such programming is through the “window system application program interface”
Window system api
Allows output control of window titles scroll bars, changing pixels, …
Allows input of mouse movements, button presses, keyboard, …

18. User Interface Programming Window System vs. Window Manager
Window Systems
Supports different screen regions
… called windows (duh)
Can be:
part of a program (Smalltalk)
a separate program (X)
A little bit of all (MS Windows)
Often divided into two layers:
1. Window Manager (base layer)
Implements the basic functionality of the windowing system
Often window manager (wm) and window system (ws) are blurred into one, since many systems (apple, windows, next) combine them as one
Others allow different wm on same ws (X)
2. Window System (UI layer)
Provides a programmer interface (API) that allows output of graphics to draw on the screen to a clipped region (window)

19. User Interface Programming Window System vs. Window Manager
Window Systems
Supports different screen regions
… called windows
Can be:
part of a program (Smalltalk)
a separate program (X)
A little bit of all (MS Windows)
Often divided into two layers:
1. Window Manager (base layer)
implements the basic functionality of the windowing system
Allows end users to move windows, resize them, iconify them, select them, etc
Provides “decorations” on windows, such as, titles, borders, colors, icons, etc
Provides primitives for generating pictures, text on the output display:
output model
provides mechanisms for handling user input (keyboard, mouse):
input model
primary interface to the base layer is through a procedural interface, API

20. User Interface Programming Window System vs. Window Manager
Window Systems
Supports different screen regions
… called windows
Can be:
part of a program (Smalltalk)
a separate program (X)
A little bit of all (MS Windows)
Often divided into two layers:
1. Window Manager (base layer)
2. Window System (UI layer)
Includes all aspects that are visible or apparent to the user
Including, presentation: what the user sees, windows, pictures, text, etc.
Provides a programmer interface (API) that allows output of graphics to draw on the screen to a clipped region (window)
output model.
Input channels from mouse/keyboard to appropriate window
input model
Commands: operations the user can use to manipulate windows and their contents

22. Interaction Handling: Event Driven
Program perspective:
Program handles events, thus event-driven programming
// general initialization, first display
While (!quit) {
// program waits for user action
wait_on (user_action) // just sit there until event occurs
switch (user_action)
case mouse_button_1_clicked
// do whatever upon mouse click
  // other cases to handle input (events)
case mouse_button_2_clicked : }
When > 1 user action occurs before completing processing of another event,
put event in queue, the event queue
In fact there is a message for just about everything, mouse move, resize, etc.,
and events are passed to the program as messages and placed in the message queue

23. A Big Idea: “Windows Distributes Events to Appropriate Event Queues”
Windows perspective:
Program 1
Program 2
Program 3
Event queue 1
Event queue 2
Event queue 3
Windproc 1
Windproc 2
Windproc 3

24. Events, Queues, Main Prog., “WndProc”
Events in window are called window messages:
  Each application has its own message queue(s)
  Each message queue is handled by a procedure, often named “WindowProc”
  Windows operating system places some messages into an application's queue,
messages, are sent directly to the appropriate WindowProc()
But first, each application (in its “main” program) has event loop polls queue for new messages:
MSG msg;
while (GetMessage (&msg, 0, 0, 0) == TRUE) {
TranslateMessage(msg);
DispatchMessage (msg); }
Write code to perform application specific processing for messages of interest
code is in the “WindowProc” for each window
“Un-interesting” messages can be passed back to the Windows operating system for default processing by calling:
  DefWindowProc ()
but, all messages are available
Periodic calls to GetMessage() are necessary to prevent an application from taking control of the machine

25. A Big Idea: “Windows Distributes Events to Appropriate Event Queues”
Windows perspective:
Program 1
Program 2
Program 3
Event queue 1
Event queue 2
Event queue 3
Windproc 1
Windproc 2
Windproc 3

26. Interaction Handling: Sampling vs. Event-driven
Sampling (or polling) vs. Event-driven
Basic issue of how to get and act upon user requests/actions/inputs
Entails “looking at” (getting information from) input devices
Readln (...) - get character or numeric information - “sits and waits”
With several asynchoronous devices (mouse loc & button, keyboard, ...)
need new methods
Example: Polling to detect mouse
// general display, etc.
// use past and current values of some event indicator to see if (new) input
old_val = get_val_of (mouse_button_1)
While (!quit) { . :
new_val = get_val_of (mouse_button_1)
if (new_val != old_val)
// do whatever you want to do upon mouse click event
old_val = new_val }
// check other devices too, and act if need to
This is process intensive as always checking - lots/mostly nothing new
May be better to have scheme in which not just keep looking - polling

27. Interaction Handling: Event Driven
Program perspective: Program handles events, thus event-driven programming
// general initialization, first display
While (!quit) {
// program waits for user action
wait_on (user_action) // just sit there until event occurs
switch (user_action)
case mouse_button_1_clicked
// do whatever upon mouse click
// other cases to handle input (events)
case mouse_button_2_clicked : }
When > 1 user action occurs before completing processing of another event,
put event in queue, the event queue
In fact there is a message for just about everything, mouse move, resize, etc.,
and events are passed to the program as messages and placed in the message queue

28. Interaction Handling: Real MS Windows API Code
Note similarity of Windows program to general structure:
WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) {
HDC hdc ;
PAINTSTRUCT ps ;
RECT rect ;
switch (iMsg)
case WM_CREATE :
[process WM_CREATE message]
return 0 ;
case WM_PAINT :
[process WM_PAINT message]
case WM_DESTROY :
[process WM_DESTROY message] }
return DefWindowProc (hwnd, iMsg, wParam, lParam) ; // lets windows handle what not handled here
Each “case” represents an event, and what to do when it occurs
Should (soon) feel (more or less) comfortable with all aspects

29. Message Loop
It is the main program which is responsible for making events/messages available to the procedure (WndProc) which handles them.
The Windows operating system terminates an application when a WM_QUIT message occurs.

30. REAL “Hello World” Code Next, Recall Event Handling: WinMain and WndProc
One last time …
Program entry point is WinMain( )
WindowProc( ) is called repeatedly to handle events/messages
WindowProc( ) is instantiated many many many … time
Is going on and off the runtime stack repeatedly
Hence, e.g., must use static variables

31. Hello World 1: ~60 lines –WinMain
HELLOWIN.C – Petzold --- (main just sets things up – quite a few things – very low level)
#include <windows.h>
LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ;
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) {
static TCHAR szAppName[] = TEXT ("HelloWin") ;
HWND hwnd ;
MSG msg ;
WNDCLASS wndclass ; // 1990’s object oriented (hack)
wndclass.style = CS_HREDRAW | CS_VREDRAW ;
wndclass.lpfnWndProc = WndProc ;
wndclass.cbClsExtra = 0 ;
wndclass.cbWndExtra = 0 ;
wndclass.hInstance = hInstance ;
wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) ;
wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) ;
wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH) ;
wndclass.lpszMenuName = NULL ;
wndclass.lpszClassName = szAppName ;
if (!RegisterClass (&wndclass))
MessageBox (NULL, TEXT ("This program requires Windows NT!"),
szAppName, MB_ICONERROR) ;
return 0 ;
} (continued)

32. WinMain (cont’d) hwnd = CreateWindow (szAppName, // window class name
hwnd = CreateWindow (szAppName, // window class name
TEXT ("The Hello Program"), // window caption
WS_OVERLAPPEDWINDOW, // window style
CW_USEDEFAULT, // initial x position
CW_USEDEFAULT, // initial y position
CW_USEDEFAULT, // initial x size
CW_USEDEFAULT, // initial y size
NULL, // parent win handle
NULL, // window menu handle
hInstance, // prog inst handle
NULL) ; // creation parameters
ShowWindow (hwnd, iCmdShow) ;
UpdateWindow (hwnd) ;
while (GetMessage (&msg, NULL, 0, 0)) {
TranslateMessage (&msg) ;
DispatchMessage (&msg) ; }
return msg.wParam ;

33. Hello World: WinProc, the Message Handler
Note similarity to paradigm message handler of any event driven architecture:
LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, L… lParam) {
HDC hdc ;
PAINTSTRUCT ps ;
RECT rect ;
switch (message)
case WM_CREATE:
PlaySound (TEXT("hellowin.wav"), NULL, SND_FILENAME | SND_ASYNC) ;
return 0 ;
case WM_PAINT: // “window redraws itself!”
hdc = BeginPaint (hwnd, &ps) ;
GetClientRect (hwnd, &rect) ;
DrawText (hdc, TEXT ("Hello, Windows 98!"), -1, &rect,
DT_SINGLELINE | DT_CENTER | DT_VCENTER) ;
EndPaint (hwnd, &ps) ;
case WM_DESTROY:
PostQuitMessage (0) ; }
return DefWindowProc (hwnd, message, wParam, lParam) ;
// DefWindProc handles all message not handled in WndProc

34. LOTS of “Windows functions” Calls
Windows Function Calls
HELLOWIN - 18 Windows functions: LoadIcon Loads an icon for use by a program.
LoadCursor Loads a mouse cursor for use by a program.
GetStockObject Obtains a graphic object, in this case a brush used for painting the window's background.
RegisterClass Registers a window class for the program's window.
MessageBox Displays a message box.
CreateWindow Creates a window based on a window class.
ShowWindow Shows the window on the screen.
UpdateWindow Directs the window to paint itself.
GetMessage Obtains a message from the message queue.
TranslateMessage Translates some keyboard messages.
DispatchMessage Sends a message to a window procedure.
PlaySound Plays a sound file.
BeginPaint Initiates the beginning of window painting.
GetClientRect Obtains the dimensions of the window's client area.
DrawText Displays a text string.
EndPaint Ends window painting.
PostQuitMessage Inserts a "quit" message into the message queue.
DefWindowProc Performs default processing of messages.

35. Summary: Event Mode – this is new

36. Event Mode – this is new
Most systems have more than one input device, each of which can be triggered at an arbitrary time by a user
Each trigger generates an event whose measure is put in an event queue which can be examined by the user program
Event types … and these may not all be what you think of as “events”
Mouse: click one or more buttons
Keyboard: press or release a key
Motion: move mouse
Window: resize, expose, iconify
Idle: “nonevent” (for heavens sake), or, the “null event”
Define what should be done if no other event is in queue

37. Event Driven Architecture
Different paradigm for control flow
Have written “while (true)” loops
Continues in loop until something terminates, e.g., menus
Also, have written polling loops
I.e., continue looping and constantly getting value (will see example)
Will look at details of event driven (software) architecture as relate to interactive systems generally
Essential challenge is the handling of asynchronous events
E.g., button presses, mouse movement, …
Whatever user does, … and whenever he or she does it
GLUT will make use of callback functions – but there are other ways
And, will look at MS Windows API to handle events, as GLUT is “abstraction”

38. About Interaction Handling, Polling
Sampling (polling) vs. event-driven software architectures
Basic issue of how to get and act upon user actions
Entails “looking at” (getting information from) input devices
Readln (...) -- get character information, “sits and waits”
With several asynchronous devices (mouse loc & button) need new method(s)
Polling to detect mouse:
// use past and current values of some event indicator to see if (new) input
old_val = get_val_of (mouse_button_1)
WHILE (!quit) {
new_val = get_val_of (mouse_button_1)
if (new_val != old_val)
// do whatever to do with mouse click
old_val = new_val }
  // check other devices too, and act if need to  }
This is process intensive as always checking

39. About Interaction Handling, Event Driven
WHILE (!quit) {
// program waits for user action
wait_on (user_action) // just sit there until event occurs, sort of a magic function, … we’ll see
switch (user_action) {
case mouse_button_1_clicked:
// do whatever to do with mouse click
// other cases to handle user input:
case mouse_button_2_clicked: . }
When > 1 user action occurs before processing of another event, put events in queue
event queue:
This is basic manner in which window manager (system) handles user input:
There is an event for everything (click, resize window, move mouse into window, ...)!
and a message is generated for each, so in fact the messages are held in a queue: window’s event, or message, queue
e1 e2 e3 e4 e5 ……

40. Window Manager Distributes Events to Appropriate Program Event Queues
E.g., mouse move across multiple programs
Information about input event distributed to all programs, e.g., mouse x, y
Every program has an event queue
Program 1
Program 2
Program 3
Event queue 1
Event queue 2
Event queue 3
Wndproc 1
Wndproc 2
Wndproc 3

41. Again, Event Driven Event driven control flow architecture:
WHILE (!quit) { :
// program waits for user action
wait_on (user_action) // just sit there until event occurs
switch (user_action) {
case mouse_button_1_clicked: // do whatever to do with mouse click
// other cases to handle user input:
case mouse_move:
// … and other window system events
case window_resized: . }
There is an event for everything (click, resize window, window, ...)!
and a message is generated for each, so in fact the messages are held in a queue: window’s message queue

42. E.g., MS Windows Callback Function like GLUT Callback Function, but handles everything! - separate functions for GLUT
WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) // front message of event queue {
switch (iMsg) // note switch structure – handles and returns
case WM_CREATE : // message when program starts :
case WM_SIZE : // message when window size changed
case WM_MOUSEMOVE :
x = LOWORD (lParam); y = HIWORD (lParam); // “decode” lParam to get x and y locations
return 0 ;
case WM_LBUTTONDOWN : // myMouse (button, state, x, y);
x = LOWORD (lParam); y = HIWORD (lParam);
TextOut (hdc, 20, 200, szBuffer, nLength); // write x and y locations
case WM_DESTROY : // window closed
PostQuitMessage (0) ; }
return DefWindowProc (hwnd, iMsg, wParam, lParam) ; // default handling of events, if not here

43. MS Windows Callback Function like GLUT Callback Function, but handles everything! - separate functions for GLUT
WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) // front message of event queue {
switch (iMsg) // note switch structure – handles and returns
case WM_CREATE : // message when program starts :
case WM_SIZE : // message when window size changed
case WM_MOUSEMOVE :
x = LOWORD (lParam); y = HIWORD (lParam); // “decode” lParam to get x and y locations
return 0 ;
case WM_LBUTTONDOWN : // myMouse (button, state, x, y);
x = LOWORD (lParam); y = HIWORD (lParam);
TextOut (hdc, 20, 200, szBuffer, nLength); // write x and y locations
case WM_DESTROY : // window closed
PostQuitMessage (0) ; }
return DefWindowProc (hwnd, iMsg, wParam, lParam) ; // default handling of events, if not here
glutMouseFunc
encapsulates several “raw” window events
in a nice function with parameters
glutReshapeFunc

44. GLUT Callback Functions
From manual:
7.1 glutDisplayFunc
7.2 glutOverlayDisplayFunc
7.3 glutReshapeFunc
7.4 glutKeyboardFunc
7.5 glutMouseFunc
7.6 glutMotionFunc, glutPassiveMotionFunc
7.7 glutVisibilityFunc
7.8 glutEntryFunc
7.9 glutSpecialFunc
7.10 glutSpaceballMotionFunc
7.11 glutSpaceballRotateFunc
7.12 glutSpaceballButtonFunc
7.13 glutButtonBoxFunc
7.14 glutDialsFunc
7.15 glutTabletMotionFunc
7.16 glutTabletButtonFunc
7.17 glutMenuStatusFunc
7.18 glutIdleFunc
7.19 glutTimerFunc
GLUT callback function is called when various events occur
E.g., WM_LBUTTON_DOWN
glutMouseFunc callback encapsulates several “raw” window events in a nice function with parameters
Some used all the time
glutDisplayFunc
More later

45. GLUT Callback Functions
Callback function is called when various events occur
E.g., WM_LBUTTON_DOWN
glutMouseFunc callback
encapsulates several “raw” window events in nice function with parameters
glutMouseFunc (myMouse);
void myMouse(int button, int state, int x, int y) {
if (button == GLUT_LEFT_BUTTON && state == GLUT_DOWN)
exit(0); }

46. Recall, Software Architecture
“Application Progs”
E.g., student programs
MS Excel, etc.
Tools: UI Program.
MFC, Swing,
Qt (widget toolkit and more)
Tools: Vis. Program.
VTK
Tools: Graphic
Maya, 3ds
Window system API
MS windows
X tools
GLUT
OpenGL Utility Toolkit
Graphics API
OpenGl (no win sys func)
DirectX
CPU
GPU
Graphics Processing Unit

47. From Blanchette book …

48. About UI Programming Systems
UI programming systems, or “toolkits”, consist of these elements
E.g., MS windows (below), Swing (AWT for Java), Motif (X-windows), Qt (cross-platform
Components (view hierarchy)
Windows and child windows
Stroke drawing package
GDI
Pixel model
Bitmaps
Input handling
Messages sent to a window procedure
Widgets
Buttons, menus, text boxes

49. Examples All programming systems have these basic elements MS Windows
Swing
HTML Qt
Components
Windows
JComponents
Elements
Strokes
GDI
Graphics
(none)
Pixels
Bitmaps
Image
Inline images
Images
Input
Messages -> window proc
Listeners
Javascript event handlers
Connections and slots
Widgets
Button, menu, textbox, …
Jbutton, Jmenu, …
Form controls, links
Button, …

50. Widgets Widget: again, “window gadget” (Qt), etc.
Controls, interactors, gizmos, gadgets
At core of Qt programming paradigm
Reusable user interface components
Examples
Buttons, checkboxes, radio buttons
List boxes, combo boxes, drop-downs
Menus, toolbars
Scrollbars, splitters, zoomers
One-line text, multiline text, rich text
Trees, tables
Simple dialogs

51. Widgets Success (or unsuccess) story for user interface programming
Advantages
Reuse of development effort
Coding, testing, debugging, maintenance
Design, iteration and evaluation
External consistency
Disadvantages
Constrain designer’s thinking
Encourage menu & forms style, rather than richer direct manipulation style
May be used inappropriately
E.g., instructions in title bar
Is WIMP all there is?
Long record of mediocre (but not really bad) interfaces

52. Widget Data Data used in widgets Embedded model Linked model
Application data must be copied into the widget
Changes must be copied out’
Linked model
Or, data binding
Application provides model satisfying an interface
Enables “data-bound” widgets, e.g. a table showing thousands of database rows, or a combo box with thousands of choices

53. UI Toolkits Often built on top of other toolkits
Can provide cross-platform portability
May add more powerful features
E.g., X Windows
XLib provides view hierarchy, stroke drawing, input handling
Xlib not provide widgets
Toolkits do
Athena
Motif
GTK+ Qt
XLib

54. UI Toolkits - Qt Cross-platform portability
Re-implements native system look and feel
Or, can have (program) internal consistency
Extends widget set, e.g., spin boxes
Qt provides C++, Java, and Python language bindings
Also, allows direct access to other sw api’s/layers, e.g., OpenGL
As well as, allows direct access to MS Windows API
But, is much more efficient to program in Qt
MS Windows
XLib
Mac

55. Qt is easy … in many ways
Example of MS Windows API

56. Hello World 1: ~60 lines –WinMain
HELLOWIN.C – Petzold --- (main just sets things up – quite a few things – very low level)
#include <windows.h>
LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ;
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) {
static TCHAR szAppName[] = TEXT ("HelloWin") ;
HWND hwnd ;
MSG msg ;
WNDCLASS wndclass ;
wndclass.style = CS_HREDRAW | CS_VREDRAW ;
wndclass.lpfnWndProc = WndProc ;
wndclass.cbClsExtra = 0 ;
wndclass.cbWndExtra = 0 ;
wndclass.hInstance = hInstance ;
wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) ;
wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) ;
wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH) ;
wndclass.lpszMenuName = NULL ;
wndclass.lpszClassName = szAppName ;
if (!RegisterClass (&wndclass))
MessageBox (NULL, TEXT ("This program requires Windows NT!"),
szAppName, MB_ICONERROR) ;
return 0 ; }
(cont’d)

57. WinMain (cont’d) hwnd = CreateWindow (szAppName, // window class name
hwnd = CreateWindow (szAppName, // window class name
TEXT ("The Hello Program"), // window caption
WS_OVERLAPPEDWINDOW, // window style
CW_USEDEFAULT, // initial x position
CW_USEDEFAULT, // initial y position
CW_USEDEFAULT, // initial x size
CW_USEDEFAULT, // initial y size
NULL, // parent win handle
NULL, // window menu handle
hInstance, // prog inst handle
NULL) ; // creation parameters
ShowWindow (hwnd, iCmdShow) ;
UpdateWindow (hwnd) ;
while (GetMessage (&msg, NULL, 0, 0)) {
TranslateMessage (&msg) ;
DispatchMessage (&msg) ; }
return msg.wParam ;

58. Hello World: WinProc, the Message Handler
Note similarity to paradigm message handler of any event driven architecture:
LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, L… lParam) {
HDC hdc ;
PAINTSTRUCT ps ;
RECT rect ;
switch (message)
case WM_CREATE:
PlaySound (TEXT("hellowin.wav"), NULL, SND_FILENAME | SND_ASYNC) ;
return 0 ;
case WM_PAINT: // “window redraws itself!”
hdc = BeginPaint (hwnd, &ps) ;
GetClientRect (hwnd, &rect) ;
DrawText (hdc, TEXT ("Hello, Windows 98!"), -1, &rect,
DT_SINGLELINE | DT_CENTER | DT_VCENTER) ;
EndPaint (hwnd, &ps) ;
case WM_DESTROY:
PostQuitMessage (0) ; }
return DefWindowProc (hwnd, message, wParam, lParam) ;
// DefWindProc handles all message not handled in WndProc

59. LOTS of “Windows functions” Calls
Windows Function Calls
HELLOWIN - 18 Windows functions: LoadIcon Loads an icon for use by a program.
LoadCursor Loads a mouse cursor for use by a program.
GetStockObject Obtains a graphic object, in this case a brush used for painting the window's background.
RegisterClass Registers a window class for the program's window.
MessageBox Displays a message box.
CreateWindow Creates a window based on a window class.
ShowWindow Shows the window on the screen.
UpdateWindow Directs the window to paint itself.
GetMessage Obtains a message from the message queue.
TranslateMessage Translates some keyboard messages.
DispatchMessage Sends a message to a window procedure.
PlaySound Plays a sound file.
BeginPaint Initiates the beginning of window painting.
GetClientRect Obtains the dimensions of the window's client area.
DrawText Displays a text string.
EndPaint Ends window painting.
PostQuitMessage Inserts a "quit" message into the message queue.
DefWindowProc Performs default processing of messages.

60. Hello, Qt!

61. Hello, Qt! 9 lines!
#include <QApplication>
#include <QLabel>
int main(int argc, char *argv[]) {
QApplication app(argc, argv);
QLabel *label = new QLabel("Hello Qt!");
label->show();
return app.exec(); }
A bit for dramatic effect, but there will be advantages
Just a label in a field with no real “main window”
Will look at some basics tonight
Slots and signals (vs. event queues), and layouts (this is a GUI builder),

62. Hello, Qt! the details
#include <QApplication> // Definitions of QApplication and #include <QLabel> // QLabel classes // Qt is truly object-oriented int main(int argc, char *argv[]) { QApplication app(argc, argv); // Creates a QApplication object to // manage app-wide resources QLabel *label = new QLabel("Hello Qt!"); // Creates a QApplication widget (used as // a window) that displays string label->show(); // Make label (window) visible return app.exec(); // Passes control to Qt } // (would also delete QLabel)

63. Handling Events: Signals and Slots
Qt not handle events (or event queue) directly
Qt widgets emit signals when user action or change of state occurs
A widget (formally defined) is an interface object – it’s appearance and actions
Signal can be connected to a function, or slot
When signal emitted the slot, or function, is executed
In example, will connect button’s clicked signal to slot, the function quit()
quit() is “built-in” QApplication function (object)

64. A Signal and A Slot
#include <QApplication> // Include class definitions #include <QPushButton> int main(int argc, char *argv[]) { QApplication app(argc, argv); // Create QApplication object QPushButton *button = new QPushButton("Quit"); // Create labeled button // Associate (connect) a particular signal (action) of this application with a slot (function) QObject::connect ( button, SIGNAL(clicked()), &app, SLOT(quit()) ); button->show(); return app.exec(); // Pass control to QT }

65. We’re done
… almost

66. Synchronization & Layout of 2 Widgets Book example – can be complex
Example code creates three widgets:
QSpinbox, QSlider, QWidget (application’s main window, will be parent of others)
Using signals and slots of the QSpinbox and QSlider, set value of one depending on value set in the other
E.g., change spinbox value to 70, slider will move to appropriate position
Change slider to some position, spinbox value will be changed based on position
“Layout manager” object will set size and position of widgets
… much more later …

67. “Setting up”, 1/3
#include <QApplication> // Include class definitions for
#include <QHBoxLayout> // layout,
#include <QSlider> // slider,
#include <QSpinBox> // and spinbox
int main(int argc, char *argv[]) {
QApplication app(argc, argv);
QWidget *window = new QWidget; // Again, window will be widget
window->setWindowTitle("Enter Your Age"); // Not good interface design!

68. Create & Synchronize Widgets, 2/3 A little “tricky” …
QSpinBox *spinBox = new QSpinBox; // Create spinbox and slider QSlider *slider = new QSlider(Qt::Horizontal); spinBox->setRange(0, 130); // Set/define range of each slider->setRange(0, 130); // As before, a particular widget (user action) signal causes a function (slot) to be called // here, when the value in the spinbox is changed, 1) the function to set the value in the // slider is called, and 2) passes the new value of the spinbox to be new value of the slider QObject::connect(spinBox, SIGNAL(valueChanged(int)), slider, SLOT(setValue(int))); // … and vice versa! QObject::connect(slider, SIGNAL(valueChanged(int)), spinBox, SLOT(setValue(int))); spinBox->setValue(35); // Set initial value for spinbox, slider will then get set

69. Layout of Widgets by Qt, 3/3
// Qt manages the relative positioning of the child windows, here, as BoxLayout QHBoxLayout *layout = new QHBoxLayout; layout->addWidget(spinBox); // Place widgets in set to be layout->addWidget(slider); // positioned window->setLayout(layout); // Installs layout manager on win window->show(); return app.exec(); }

70. We’re done - really
Styles
IDE
Help

71. Widget Styles Recall, Qt is cross-platform
Can have Qt applications in windowing system style where executed (external consistency) or in same style across windowing systems (internal consistency)

72. Qt IDE
Works fine

73. Qt IDE
Open project
Open file

74. Help
Works fine

75. Help
Works fine

76. End .