[openglean-devel]Reflections.

[Richard R. <sf...@ol...>]

Well, partly I'm writing this email since a couple of posts to another
list have bounced (possibly).

Another reason that I'm writing this post is to share some reflections
that I've had about error handling.  (See the recent OpenGLEAN API
proposal for allowing glut* functions to fail, where GLUT traditionally
either succeeded to crashed your program.)

When starting to mix libraries (e.g., an add-on menu library), it
would become relavent to know which error handler was called first
if, e.g., a menu window could not be opened.  The menu code almost
certainly would want to control that (for opening menu windows) to
simply return.  But what if the main client application has registered
its own error handler?  Whose gets called?  What if we call the main
application's handler, how can it invoke the menu handler?  It would
seem desirable to have the ability to cascade callbacks in some way.

One solution is to define glutGetfptr(enum FptrName), and allow one to
retrieve error handler function pointers (and other types, for that
matter, such as keyboard and mouse handlers).  This appears to solve
the problem, but can result in a bit of a mess for cascading handlers.
(And the order in which handlers are registered would still be and issue.
E.g., a menu system would want to get mouse events before the main
application can see them, in case the menu library is expected to
devour the event and produce a menu.)


Perhaps a cooperative environment between client application and,
e.g., menu library, is reasonable.  It just seems to be straying
rather far from the ideal of simplicity.


In any case, because of the issue of cascading callbacks, a final
API decision hasn't been reached for graceful failures, so there
is no implementation at this point.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/