module Gui_action_adapter:Abstract base class defining the interface by which
OsgGA.Gui_event_handlers may request actions of the GUI system in use. These requests for actions should then be honoured by the GUI toolkit of the user's application.
To provide more detail, when a
OsgGA.Gui_event_handler (e.g. a TrackballManipulator)
handles an incoming event, such as a mouse event, it may wish to make
a request of the GUI. E.g. if a model is 'thrown', the trackball manipulator
may wish to start a timer, and be repeatedly called, to continuously refresh the
camera's position and orientation. However, it has no way of doing this, as it
knows nothing of the window system in which it's operating. Instead, the
OsgGA.Gui_event_handler issues it's request via a Gui_action_adapter, and the viewer
in use should honour the request, using the GUI system in play.
There is more than one way of using the Gui_action_adapter. E.g. it may be inherited
into a Viewer class, as is done with osgGLUT::Viewer. Alternatively, a simple
subclass of Gui_action_adapter (e.g. osgQt::QtActionAdapter) may be passed to
OsgGA.Gui_event_handler::handle() function; once the function has returned, the viewer
will then unpack the results and work out what to do to respond to the
Also there are several ways to run your app and handle the updating of the window. osgGLUT::Viewer always has a idle callback registered which does a redraw all the time. osgGLUT::Viewer can safely ignore both requestRedraw() and requestContinousUpdate() as these are happening all the time anyway.
Other apps will probably want to respond to the requestRedraw() and
requestContinousUpdate(bool) and again there is more than one way to handle it.
You can override requestRedraw() and implement to call your own window
redraw straight away. Or you can implement so that a flag is set and
then you then respond the flag being set in your own leisure.