Introduction to Visual Programming

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

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

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

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

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

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

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

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

Method #2 Interrupt-driven Processing • Enable device, then • proceed with “background” processing until an interrupt is received, at which point • Save state (context-switch) • Respond to input • Restore state and go to step #2. What advantages/disadvantages does this have?

Method #3: Event-driven Processing Interaction is once again governed by a loop: Loop forever: { if (event) then respond else do (one unit of) background processing or go to sleep (for one unit) }

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

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

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

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

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

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

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

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

Examples of widgets • Text editing windows (canvases) • Push buttons • Menus • Sliders • Radio buttons • LED displays • Borders

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

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

Introduction to Visual Programming