OK, I admit it, I can't stay away from it.

I'm adding two new functions to the "freeglut" interface:

void glutMainLoopEvent ( void ) - contains the guts of "glutMainLoop" and allows the application programmer to use his own (or another library's) event loop controller.  I think this will also allow re-entrant GLUT calls, where you invoke "glutMainLoopEvent" from within a GLUT callback.  I haven't tried this one out yet.

void glutLeaveMainLoop ( void ) - sets the execution state to STOP so that "freeglut" will drop out of the main loop and (1) clean up after itself and (2) if specified, return control to the calling program.  I needed to do this because my 50-window application has some memory leaks in it and I needed to try to figure out which ones were caused by GLUT/freeglut [officially not my problem, but given my recent activity in "freeglut" probably my problem], which ones were caused by PUI [not just my problem--I can share it with the PLIB developer community], and which ones were caused by my application [definitely my problem].  Having "freeglut" destroy its windows and PUI deallocate its widgets removed two-thirds of my memory leaks.

These functions are certainly not cast in stone at this point and if anybody has any suggestions on implementations and desired behaviours please speak up.  For myself, I have one definite question about behaviour:

Should the "glutMainLoopEvent" function set the execution state flag to "running"?  That way the application programmer can (in theory at least) do the following:

        - call "glutMainLoop" to start processing
        - call "glutMainLoop" again from a callback to make some re-entrant processing
        - call "glutLeaveMainLoop" to exit from the re-entrant processing
        - call "glutMainLoopEvent" to reset the execution state flag to "running" so that the main processing loop doesn't exit.

Without this behaviour the application programmer will have to have his own event loop controller for re-entrant processing.

Please note that I haven't tested out any of this re-entrant processing stuff yet.  I am putting this out to the community earlier rather than later so that I don't have to rework stuff.

John F. Fay
john.fay@eglin.af.mil