[openglean-devel]Status...

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

OpenGLEAN development has slowed considerably, but not stopped.  I spent
more time than I cared to hunting down a bug that proved to come from
the OpenGLUT days.  (It only affects WIN32; this is not surprising as
WIN32 has been largely neglected in OpenGLUT for some time before
OpenGLEAN was forked.)

I've found two more problems with OpenGLEAN, now that that bug is
fixed, and new bug reports were opened on them.  I think that I'll
try to do a version bump after I fix those (unless more problems show
up), and provide a binary WIN32 release.


<rant>The WIN32 API is a royal pain.  It seems that there are two
ways you can get messages from WIN32: One is by polling a message
queue, and the other is by callbacks that WIN32 directly does to
client code.  (At least, that's my current understanding.)  The
result is that when a window is first created, long before the
OpenGLEAN main event loop is set up and running, WIN32 may
presumptively call into the event callback code.  In fact, as
OpenGLEAN then calls WIN32 API functions which in turn may further
call back OpenGLEAN, we can get at least 2 or 3 levels of recursion
in the event handler.  Since this is happening before the WIN32
API call for window creation has returned a window handle, there
is no way for the client to have registered callbacks, and other
OpenGLEAN state may not be prepared for handling events.  This is
really nasty.  However, maybe we can store the WIN32 events in a
linked list and process them on our own time.  If we can force
WIN32 to not do direct callbacks when we are not prepared for them,
that would also be good.</rant>

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