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 Now, we will be learning the “craft” of programming for interactive systems

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

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!

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

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

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

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

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

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

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

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

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 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, …

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: Program 1 Program 2 Program 3 Event queue 1 Event queue 2 Event queue 3     Windproc 1 Windproc 2 Windproc 3

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

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

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] 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

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.

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

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)

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 ;

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

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   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 ……

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

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

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

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

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

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) 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

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 (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

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, …

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 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

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

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

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) ; 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)

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 ;

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

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> // 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)

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 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 }

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 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!

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

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(); }

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 .