More on Widgets, Misc. Topics

1
More on Widgets, Misc. Topics

• Glenn G. ChappellCHAPPELLG_at_member.ams.org
• U. of Alaska Fairbanks
• CS 381 Lecture Notes
• Friday, October 10, 2003

2
ReviewBuild-A-Button 1/2

• Last time we discussed the design of a simple
  button widget class.
• Process
• Requirements
• Then (for each class), ask
• What does the class need to be able to do?
• What must the class know?
• This can be converted into a list of function
  data members.
• Data members are only necessary for information
  that must be remembered between calls.
• Lastly, the class is implemented.
• See button.h button.cpp, on the web page.
• The program colorchange.cpp gives a demo.
• The next page summarizes our final design.

3
ReviewBuild-A-Button 2/2

• Function Members
• Display.
• Called by GLUT display function.
• Handle mouse click.
• Called by GLUT mouse function with its params.
• Handle mouse motion.
• Called by GLUT motion function with its params.
• Configure button.
• Several function members (one for each of starred
  data members).
• Default constructor.
• Destructor.

• Data Members
• Position.
• Left, bottom.
• Size.
• Width, height.
• Text label.
• Pointer to action callback function.
• Enabled?
• I call this active in the Button class.
• Currently tracking mouse?
• Pressed?

4
More on WidgetsShow/Hide

• Many good ideas were suggested for the button
  class last time. Some of these are not in the
  implementation.
• In particular, we did not give our button class a
  show/hide feature. Why was this a bad idea?
• Not having show/hide makes it difficult to manage
  large collections of buttons that are not all
  used at once.
• In the button-configuration functions, should
  glutPostRedisplay be called? We cannot tell if we
  do not know whether the button is visible.

5
More on WidgetsWidget Manager

• Most GUI toolkits include some kind of widget
  manager.
• A widget manager handles many of the mindless
  details of widgets displaying them all, checking
  for mouse clicks, etc.
• Thus, you need only make a new widget and tell
  the manager about it. The rest is handled for
  you, except for the code to perform the widgets
  action.
• Some widget managers handle widget creation as
  well.
• A manager could handle show/hide, even for
  widgets that do not support it.
• Along with the list of widgets, store a show/hide
  flag for each one. Then simply avoid calling the
  display and mouse-handling routines for hidden
  buttons.
• Write a simple widget manager for full credit on
  Assignment 5.

6
More on WidgetsInheritance

• Widget classes are a good application of C
  inheritance polymorphism (IMHO there are lots
  of bad applications)
• Create a Widget class on which all other widgets
  are based.
• Then a separate derived class could be written
  for each of the various types of widget.
• Functions that all widgets use (display, handle
  mouse, handle motion) could be virtual functions.
• Then a widget manager would store only a pointer
  to each widget.
• The manager simply calls the virtual function for
  each widget it does not need to know what kind
  of widgets it is managing.
• So new kinds of widgets can be created without
  rewriting the manager.
• Warning Inheritance does not work well with STL
  containers unless a smart pointer class is
  used. See me if you are interested in the details.

7
More on WidgetsButton Checkbox

• What is the difference between a button and a
  checkbox?
• Users point of view very different.
• Buttons initiate actions.
• Checkboxes do nothing permanent they only set
  flags that can be reset by clicking again.
• Programmers point of view very similar.
• The display functions are completely different,
  of course.
• Other than that, the main difference is that a
  button has an action function, while a checkbox
  has a boolean.
• What changes would we need to make to the Button
  class to implement a checkbox?
• Completely re-do the display function.
• Unless you want a really ugly checkbox.
• Get rid of the action function and its associated
  configuration call.
• Add a bool with its associated configuration
  call, and a new function to return its value.
• When a mouse down-up is detected, instead of
  calling the action function, toggle the bool.

8
Note on Time-Dependent Motion

• We have looked at making objects move.
• Typically, we move an object a certain amount
  each idle call.
• This means objects will move faster on faster
  systems.
• What if we want speeds to be the same on all
  systems?
• Solution Use the clock.
• The amount of time since the program started is
  given by stdclock, declared in ltctimegt.
• To get the time in secondsdouble(clock())/CLOCKS
  _PER_SEC
• To get the elapsed time since the previous idle
  call
• Save the old time before leaving idle.
• Subtract old from new.
• Now, to find out how far to move an object,
  multiply the elapsed time by the speed of the
  object.
• See timedep.cpp for example code.

9
Preview of TransformationsIntroduction

• Next week we discuss the mathematical basis of
  3-D CG.
• This will make available to us one of the more
  powerful concepts in 3-D CG transformations.
• Here is a preview, so you can use them now, if
  you want.
• A transformation is a way of transforming
  points/objects
• Moving (translating) them.
• Rotating them about some line.
• Resizing (scaling) them, using some point as the
  center.
• Projecting them on the screen.
• Etc.
• OpenGLs primary transformation is the model/view
  transformation, stored in the model/view matrix.
• To change this matrix, doglMatrixMode(GL_MODELVIE
  W)then apply one or more transformation
  commands.
• I usually do glMatrixMode in my reshape function.

10
Preview of TransformationsCode Overview

• Setting up a transformation, and then using it,
  usually works as follows.
• // We are somewhere in the display callback
• glPushMatrix() // Save transformation
• Set the transformation here,
• using glTranslated, glRotated, and/or
  glScaled.
• Drawing code that uses the transformation goes
  here.
• glPopMatrix() // Restore saved transformation

11
Preview of TransformationsTransformation
Commands

• The three main transformation commands
• Function glTranslated translates (moves) objects.
• Three parameters x, y, and z coordinates of
  amount to move.
• In 2-D, doglTranslated(x, y, 0.)
• Function glRotated rotates objects about a line
  through the origin.
• Four parameters angle to rotate (degrees), x, y,
  and z coordinates of vector to rotate about.
• In 2-D, doglRotated(angle, 0.,0.,1.)to rotate
  counterclockwise about the origin.
• Function glScaled scales (resizes) objects,
  centered at the origin.
• Three parameters amount to scale in x, y, and z
  directions.
• Typically these are all the sameglScaled(size,
  size, size)
• Unless you are sure you know what you are doing,
  the transformation commands should come in this
  order translate, then rotate, then scale.
• You can leave out one or more, but dont reorder
  them.

12
Preview of TransformationsExample

• Say we have a function drawsquare (no parameters)
  that draws a square with side 1, centered at the
  origin.
• How can you use this function, and the
  transformation commands, to draw a square of side
  7, centered at the point (3, 2)?
• glPushMatrix() // Almost always comes first!
• glTranslated(-3, 2, 0) // Indenting is good.
• glScaled(7, 7, 7) // Translate then
  scale.
• drawsquare()
• glPopMatrix() // Almost always comes last!