Module OsgGA.Gui_action_adapter

module Gui_action_adapter: sig .. end

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 the 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 requests.

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.

type t