introduction to visual programming l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction to Visual Programming PowerPoint Presentation
Download Presentation
Introduction to Visual Programming

Loading in 2 Seconds...

play fullscreen
1 / 21

Introduction to Visual Programming - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Introduction to Visual Programming' - foy


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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
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
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
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
  • 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
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
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
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
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
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
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
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
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
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
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
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
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
Examples of widgets
  • Text editing windows (canvases)
  • Push buttons
  • Menus
  • Sliders
  • Radio buttons
  • LED displays
  • Borders
building a gui
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
Acknowledgements
  • Some of the slides were originally written by J. Ross Beveridge, updated by Dale Roberts.