Because the ViewPlatform provide support for
"constant aspect ratio" in scenes, it is necessary
to keep the ViewPlatform updated regarding the current
aspect ratio of the ViewPort. This implementation
merely calls the platform's setViewport, then
calls the super-class ViewPort method.

XXX
Unfortunately, because Context objects may be
old-style classes, we can't use super(), so
this implementation actually calls
context.Context.ViewPort directly.

This is the primary client API for dealing with the event system.
Each event class will define a particular set of data values
required to form the routing key for the event. Each event handler
class will define a registerCallback function which converts
its arguments into a matching key.

This function merely determines the appropriate handler then
dispatches to the handler's registerCallback method (without the
eventType argument).

This temporarily replaces a particular manager within the
dispatch set with provided manager. This will normally be
used to create "modal" interfaces such as active drag
functions (where the interface is in a different "interaction
mode", so that actions have different meaning than in the
"default mode").

Passing None as the manager will restore the previous manager
to functioning.

Note: this function does not perform a "system capture"
of input (that is, mouse movements are only available if they
occur over the context's window and that window has focus).

Note: for capturing mouse input, you will likely want to
capture both movement and button events, it should be possible
to define a single handler to deal with both event types,
and pass that handler twice, once for each event type.

This method provides a customization point where
contexts which do not completely initialize during
their __init__ method can arrange to have the OnInit
method processed after their initialization has
completed. The default implementation here simply
calls OnInit directly w/ appropriate setCurrent
and unsetCurrent calls and calls the glutInit()
function with an empty argument-list.

The RenderPasses define the core of the rendering
mechanism. The default rendering passes will defer
most rendering options to the scenegraph returned bygetSceneGraph(). If that value is None (default)
then the pass will use the Context's callbacks.

You can define new RenderPasses to replace the
rendering algorithm, override the Context's various
callbacks to write raw OpenGL code, or work by
customizing the scene graph library.
* if there was a visible change (which is the return value
from the render-pass-set), calls SwapBuffers()
* calls unsetCurrent()

This method is called by the default render passes to
render the geometry for the system. Wherever possible,
you should pay attention to the rendering modes to allow
for optimization of your geometry (for instance,
selection passes do not require lighting).

The default implementation merely ensures that matrix mode
is currently model view.

See: visitor.py, rendervisitor.py, renderpass.py,
shadow/passes.py for definitions of the properties of the
mode.

This is a method of the Context, rather than the
rendering pass (which might seem more elegant given
that it is the rendering pass which deals with the
events being registered) because the requests to
render a pick event occur outside of the rendering
loop. As a result, there is (almost) never an
active context when the pick-event-request comes in.

Subclasses and applications will register events
here for those event types in which they are interested.
Most minor applications should use interactivecontext's
abstract callbacks (which translate the GUI library's
native events into a common event framework for all
interactivecontexts).