Transcript Qt Introduction (Ch. 1) - ppt

QT – Introduction
C++ GUI Programming with Qt 4
Blanchette and Summerfield, Ch. 1
Miller, 2004
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
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, …
Overview of Interactive Systems
Focus on Programming
• Humans (open system)
interact with
computers (closed system)
primarily through
displays - and input devices
Open
System
User, i.e., Human
“Interaction” “Perception” “Information”
Closed
System
Display
Programming systems
-windows
-graphics
• Now, we will be learning the
“craft” of programming for
interactive systems
An illusion:
analog world
represented
digitally
Programming is a craft
Hardware and
graphics engines
Lights
Rendering
Drawing
Algorithms
3-D
Viewing
Representation of
curves and surfaces
“Models”,
(Foley et al. term)
Transformation
Overview of Interactive Systems
Focus on Programming
• Humans (open system)
interact with
computers (closed system)
primarily through
displays - and input devices
Open
System
User, i.e., Human
“Interaction” “Perception” “Information”
Closed
System
Display
Programming systems
-windows
-graphics
• Now, we will be learning the
“craft” of programming for
interactive systems
An illusion:
analog world
represented
digitally
Programming is a craft
Hardware and
graphics engines
Lights
Rendering
Drawing
Algorithms
3-D
Viewing
Representation of
curves and surfaces
“Models”,
(Foley et al. term)
Transformation
Overview of Interactive Systems
Focus on Programming
• Humans (open system)
interact with computers
(closed system) primarily
through displays - and input
devices
Open
System
User, i.e., Human
“Interaction” “Perception” “Information”
Closed
System
Programming systems
-windows
-graphics
• 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!
Display
An illusion:
analog world
represented
digitally
Programming is a craft
Hardware and
graphics engines
Lights
Rendering
Drawing
Algorithms
3-D
Viewing
Representation of
curves and surfaces
“Models”,
(Foley et al. term)
Transformation
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
application program
OpenGL Motif
widget or similar
window
system
GLUT, Qt
GLX, AGL
or WGL
X, MS Windows, Mac os
GLU
GL
software and/or hardware
graphics
system
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”
application program
OpenGL Motif
widget or similar
window
system
GLUT, Qt
GLX, AGL
or WGL
X, Win32, Mac O/S
GLU
GL
software and/or hardware
graphics
system
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)
application program
OpenGL Motif
widget or similar
window
system
GLUT, Qt
GLX, AGL
or WGL
X, Win32, Mac O/S
GLU
GL
software and/or hardware
graphics
system
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
CPU
Graphics API
OpenGl (no win sys func)
DirectX
GPU
Graphics Processing Unit
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
CPU
GLUT
OpenGL Utility Toolkit
Graphics API
OpenGl (no win sys func)
DirectX
GPU
Graphics Processing Unit
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
CPU
Graphics API
OpenGl (no win sys func)
DirectX
GPU
Graphics Processing Unit
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
CPU
GLUT
OpenGL Utility Toolkit
Graphics API
OpenGl (no win sys func)
DirectX
GPU
Graphics Processing Unit
Software Architecture, All
“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
CPU
Tools: Vis. Program.
Tools: Graphic
VTK
GLUT
OpenGL Utility Toolkit
Maya, 3ds
Graphics API
OpenGl (no win sys func)
DirectX
GPU
Graphics Processing Unit
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
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
User Interface Programming
Window Systems
• In fact, there is are software layers
(“window system”, etc.) between
the input and output of “regular”
programming
Open
System
User, i.e., Human
“Interaction” “Perception” “Information”
Closed
System
• 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, …
Display
Programming systems
-windows
-graphics
An illusion:
analog world
represented
digitally
Programming is a craft
Hardware and
graphics engines
Lights
Rendering
Drawing
Algorithms
3-D
Viewing
Representation of
curves and surfaces
“Models”,
(Foley et al. term)
Transformation
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)
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
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
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
A Big Idea:
“Windows Distributes Events to Appropriate Event Queues”
Windows perspective:
Windows - distributes events
Program 1
program 1
program n
queue 1
queue n
wndproc()
{
}
wndproc()
{
}
Event queue
1
Windproc
1
Program 2
Event queue 2
Windproc
2
Program 3
Event queue
3
Windpro
c3
Events, Queues, Main Prog., “WndProc”
Events in window are called window messages:
Microsoft Windows
Windows API
But first, each application (in its “main” program)
has event loop polls queue for new messages:
messages
program start
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()
API Calls
WinMain()
- initialization
- define windows
- create windows
- message loop
WindowProc()
- process
messages
Windows Application
MSG msg;
while (GetMessage (&msg, 0, 0, 0) == TRUE)
{
TranslateMessage(msg);
DispatchMessage (msg);
}
Windows OS
Message?
no
run another
application
yes
Get the
message
Write code to perform application specific processing for messages of interest
code is in the “WindowProc” for each window
no
yes
“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
WM_QUIT?
WinMain()
{ ...
//message loop
while (GetMessage (msg, 0, 0)
{
// make available to WndProc
}
}
Windows Application
A Big Idea:
“Windows Distributes Events to Appropriate Event Queues”
Windows perspective:
Windows - distributes events
Program 1
program 1
program n
queue 1
queue n
wndproc()
{
}
wndproc()
{
}
Event queue
1
Windproc
1
Program 2
Event queue 2
Windproc
2
Program 3
Event queue
3
Windpro
c3
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
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
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]
return 0 ;
case WM_DESTROY :
[process WM_DESTROY message]
return 0 ;
}
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
Message Loop
Windows OS
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.
Message?
no
run another
application
yes
Get the
message
no
yes
WM_QUIT?
WinMain()
{ ...
//message loop
while (GetMessage (msg, 0, 0)
{
// make available to WndProc
}
}
Windows Application
REAL “Hello World” Code Next,
Recall Event Handling: WinMain and WndProc
One last time …
Microsoft Windows
Program entry point is WinMain( )
Is going on and off the runtime
stack repeatedly
Hence, e.g., must use static
variables
messages
WindowProc( ) is instantiated
many many many … time
program start
WindowProc( ) is called repeatedly
to handle events/messages
Windows API
API Calls
WinMain()
- initialization
- define windows
- create windows
- message loop
WindowProc()
- process
messages
Windows Application
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") ;
Microsoft Windows
HWND
hwnd ;
MSG
msg ;
Windows API
WNDCLASS wndclass ;
// 1990’s object oriented (hack)
messages
if (!RegisterClass (&wndclass))
{
MessageBox (NULL, TEXT ("This program requires Windows NT!"),
szAppName, MB_ICONERROR) ;
return 0 ;
}
program start
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 ;
API Calls
WinMain()
- initialization
- define windows
- create windows
- message loop
WindowProc()
- process
messages
Windows Application
(continued)
WinMain (cont’d)
}
Microsoft Windows
Windows API
messages
while (GetMessage (&msg, NULL, 0, 0))
{
TranslateMessage (&msg) ;
DispatchMessage (&msg) ;
}
return msg.wParam ;
// window class name
// window caption
// window style
// initial x position
// initial y position
// initial x size
// initial y size
// parent win handle
// window menu handle
// prog inst handle
// creation parameters
program start
hwnd = CreateWindow (szAppName,
TEXT ("The Hello Program"),
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL) ;
ShowWindow (hwnd, iCmdShow) ;
UpdateWindow (hwnd) ;
API Calls
WinMain()
- initialization
- define windows
- create windows
- message loop
WindowProc()
- process
messages
Windows Application
Hello World: WinProc, the Message Handler
Note similarity to paradigm message handler of any event driven architecture:
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) ;
return 0 ;
case WM_DESTROY:
PostQuitMessage (0) ;
return 0 ;
}
return DefWindowProc (hwnd, message, wParam, lParam) ;
// DefWindProc handles all message not handled in WndProc
}
Windows API
messages
switch (message)
{
case WM_CREATE:
PlaySound (TEXT("hellowin.wav"), NULL, SND_FILENAME | SND_ASYNC) ;
return 0 ;
Microsoft Windows
program start
LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, L… lParam)
{
HDC
hdc ;
PAINTSTRUCT ps ;
RECT
rect ;
API Calls
WinMain()
- initialization
- define windows
- create windows
- message loop
WindowProc()
- process
messages
Windows Application
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.
Summary: Event Mode – this is new
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
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”
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
About Interaction Handling, Event Driven
• 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:
•
e1 e2 e3
e4 e5
……
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
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
Windows - distributes events
program 1
program n
queue 1
queue n
wndproc()
{
}
wndproc()
{
}
Again, Event Driven
• Event driven control flow architecture:
WHILE (!quit)
{
:
// program waits for user action
wait_on (user_action)
switch (user_action) {
:
case mouse_button_1_clicked:
// just sit there until event occurs
// 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
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)
{
switch (iMsg)
{
case WM_CREATE :
:
case WM_SIZE :
case WM_MOUSEMOVE :
x = LOWORD (lParam);
:
return 0 ;
y = HIWORD (lParam);
case WM_LBUTTONDOWN : // myMouse (button, state, x, y);
x = LOWORD (lParam);
y = HIWORD (lParam);
TextOut (hdc, 20, 200, szBuffer, nLength);
return 0 ;
case WM_DESTROY :
PostQuitMessage (0) ;
return 0 ;
}
return DefWindowProc (hwnd, iMsg, wParam, lParam) ;
}
// front message of event queue
// note switch structure – handles and returns
// message when program starts
// message when window size changed
// “decode” lParam to get x and y locations
// write x and y locations
// window closed
// default handling of events, if not here
MS Windows Callback Function
like GLUT Callback Function, but handles everything! - separate functions for GLUT
WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
{
switch (iMsg)
{
case WM_CREATE :
:
case WM_SIZE :
case WM_MOUSEMOVE :
x = LOWORD (lParam);
:
return 0 ;
y = HIWORD (lParam);
case WM_LBUTTONDOWN : // myMouse (button, state, x, y);
x = LOWORD (lParam);
y = HIWORD (lParam);
TextOut (hdc, 20, 200, szBuffer, nLength);
return 0 ;
case WM_DESTROY :
PostQuitMessage (0) ;
return 0 ;
}
return DefWindowProc (hwnd, iMsg, wParam, lParam) ;
// front message of event queue
// note switch structure – handles and returns
// message when program starts
// message when window size changed
// “decode” lParam to get x and y locations
// write x and y locations
// window closed
// default handling of events, if not here
}
glutMouseFunc
encapsulates several “raw” window events
in a nice function with parameters
glutReshapeFunc
GLUT Callback Functions
• 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
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 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);
}
Recall, Software Architecture
“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
CPU
Tools: Vis. Program.
Tools: Graphic
VTK
GLUT
OpenGL Utility Toolkit
Maya, 3ds
Graphics API
OpenGl (no win sys func)
DirectX
GPU
Graphics Processing Unit
From Blanchette book …
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 (crossplatform
• 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
Examples
• All programming systems have these basic elements
MS Windows
Swing
HTML
Qt
Components
Windows
JComponents
Elements
Windows
Strokes
GDI
Graphics
(none)
Graphics
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, …
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
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
Widget Data
• Data used in widgets
• Embedded 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
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+
XLib
Qt
UI Toolkits - Qt
• Cross-platform portability
•
•
Re-implements native system look and feel
Or, can have (program) internal consistency
Qt
MS Windows
XLib
Mac
• 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 is easy …
in many ways
• Example of MS Windows API
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) ;
messages
program start
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int
iCmdShow)
Microsoft Windows
{
static TCHAR szAppName[] = TEXT ("HelloWin") ;
Windows API
HWND
hwnd ;
MSG
msg ;
API Calls
WNDCLASS wndclass ;
wndclass.style
= CS_HREDRAW | CS_VREDRAW ;
wndclass.lpfnWndProc = WndProc ;
wndclass.cbClsExtra = 0 ;
WinMain()
wndclass.cbWndExtra = 0 ;
WindowProc()
- initialization
- process
wndclass.hInstance = hInstance ;
- define windows
messages
- create windows
wndclass.hIcon
= LoadIcon (NULL, IDI_APPLICATION) ;
- message loop
wndclass.hCursor
= LoadCursor (NULL, IDC_ARROW) ;
Windows Application
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 ;
}
WinMain (cont’d)
}
Microsoft Windows
Windows API
messages
while (GetMessage (&msg, NULL, 0, 0))
{
TranslateMessage (&msg) ;
DispatchMessage (&msg) ;
}
return msg.wParam ;
// window class name
// window caption
// window style
// initial x position
// initial y position
// initial x size
// initial y size
// parent win handle
// window menu handle
// prog inst handle
// creation parameters
program start
hwnd = CreateWindow (szAppName,
TEXT ("The Hello Program"),
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL) ;
ShowWindow (hwnd, iCmdShow) ;
UpdateWindow (hwnd) ;
API Calls
WinMain()
- initialization
- define windows
- create windows
- message loop
WindowProc()
- process
messages
Windows Application
Hello World: WinProc, the Message Handler
Note similarity to paradigm message handler of any event driven architecture:
messages
switch (message)
{
case WM_CREATE:
PlaySound (TEXT("hellowin.wav"), NULL, SND_FILENAME | SND_ASYNC) ;
return 0 ;
Windows API
program start
LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, L… lParam)
{
HDC
hdc ;
PAINTSTRUCT ps ;
RECT
rect ;
Microsoft Windows
API Calls
WinMain()
- initialization
- define windows
- create windows
- message loop
WindowProc()
- process
messages
Windows Application
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) ;
return 0 ;
case WM_DESTROY:
PostQuitMessage (0) ;
return 0 ;
}
return DefWindowProc (hwnd, message, wParam, lParam) ;
// DefWindProc handles all message not handled in WndProc
}
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.
Hello, Qt!
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),
Hello, Qt!
the details
#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();
}
// Definitions of QApplication and
// QLabel classes
// Qt is truly object-oriented
// Creates a QApplication object to
//
manage app-wide resources
// Creates a QApplication widget (used as
//
a window) that displays string
// Make label (window) visible
// Passes control to Qt
//
(would also delete QLabel)
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)
A Signal and A Slot
#include <QApplication>
#include <QPushButton>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QPushButton *button = new QPushButton("Quit");
// Include class definitions
// Create QApplication object
// 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
We’re done
• … almost
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 …
“Setting up”, 1/3
#include <QApplication>
#include <QHBoxLayout>
#include <QSlider>
#include <QSpinBox>
// Include class definitions for
// layout,
// slider,
// and spinbox
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QWidget *window = new QWidget;
window->setWindowTitle("Enter Your Age");
// Again, window will be widget
// Not good interface design!
Create & Synchronize Widgets, 2/3
A little “tricky” …
QSpinBox *spinBox = new QSpinBox;
QSlider *slider = new QSlider(Qt::Horizontal);
// Create spinbox and slider
spinBox->setRange(0, 130);
slider->setRange(0, 130);
// Set/define range of each
// 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
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);
layout->addWidget(slider);
// Place widgets in set to be
// positioned
window->setLayout(layout);
// Installs layout manager on win
window->show();
return app.exec();
}
We’re done - really
• Styles
• IDE
• Help
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)
Qt IDE
• Works fine
Qt IDE
• Open
project
• Open file
Help
• Works fine
Help
• Works fine
End
• .