RE: [Freeglut-developer] RE: Window Destruction Callback

[Stephen J B. <sj...@li...>]

On Wed, 23 Oct 2002, Fay John F Contr AAC/WMG wrote:

> We may be talking about different things here.  I thought Jim was talking
> about supporting both the "void glutCloseFunc ( void )" and the "void
> glutWMCloseFunc ( void )" names, rather than supporting two different
> functionalities.  Supporting both names is incredibly simple; you just have
> two functions in your API.  One extra line in the header file and five extra
> lines in the C file.  We could probably do it even more simply with a
> "#define glutWMCloseFunc glutCloseFunc" statement in the header file.  (If
> anybody knows for sure that this will work, please tell me.)

Right - it'll *work* - but it's a bit confusing for the application
writer if he's tracing through with the debugger or something looking
for 'glutWMCloseFunc' - only to find that this "function" is never
called (because it's really 'glutCloseFunc').  Hence, I have a slight
preference for making a three line function called glutWMCloseFunc
that calls glutCloseFunc.

(I've been gradually replacing #define's in PLIB for this reason).

>  And I agree
> that we don't need a configuration file for this.

Good.

> As for a behaviour, I think we should by default do what GLUT does:
> 	- if the user has specified a "close function", call it and close
> the window (GLUT does not do this because it has no way to specify a "close
> function")
> 	- if the user has not specified a "close function" (which is the
> GLUT default case), halt execution.

Yes.

> Steve has suggested a third behaviour, by which the application can set a
> "do not exit on 'x' click" flag.  This also is compatible with default GLUT
> behaviour because GLUT doesn't have this sort of flag.  If somebody will
> tell me a good API call for this I will put it in.

GLUT generally uses functions called 'glutSet{something}' for setting
flags and options - so I suggest:

   #define GLUT_EXIT_IMMEDIATELY     0
   #define GLUT_RETURN_FROM_MAINLOOP 1

   void glutSetFinalWindowCloseBehavior ( int option ) ;

...(although shorter names would be preferable) - with GLUT_EXIT_IMMEDIATELY
as the default.

> The question of how to halt execution is a separate matter.  Ideally we have
> three options:
> 	(1) Call "exit" from way down in the call stack.  Apparently GLUT
> does this but some people consider this inelegant.

Only on Windoze platforms where failure to cleanup on exit tends to eat
system resources that can only be returned with a reboot.

Under all other 'real' OS's, the OS cleans up after you (because we don't
trust the application) and a simple 'exit(0)' will do.

However, even using 'exit' should be OK because you can use the 'atexit()'
or 'on_exit' functions if you want to cleanup.  There was a problem with
GLUT in that it somehow exited WITHOUT allowing the atexit/on_exit calls
to happen (I think it did '_exit()' - which bypasses all that stuff).

> 	(2) Come back to "glutMainLoop" to allow windows and their contents
> the chance to close up shop gracefully, then call "exit" from
> "glutMainLoop".

That's going to be nicer - although we run the risk that something
*else* might run between the 'X' being hit and actually exiting (eg
a timer callback or something).  We'd have to be quite careful about
that I think.

> 	(3) Have "glutMainLoop" return control to the calling program.  This
> would break existing applications where the programmer has some dummy code
> after "glutMainLoop" that he doesn't want executed but he doesn't want to
> erase.

Right - and I think you should have to use:

   glutSetFinalWindowCloseBehavior ( GLUT_RETURN_FROM_MAINLOOP ) ;

...in order to get this behaviour.  (1) or (2) should be the default.

Having said all that, I don't think it's all that critical.  If we
always did (3), I'd be quite suprised to find any existing GLUT programs
that didn't work.  After all, if glutMainLoop never returns, why would
you place any code after it?

Every GLUT program I've ever seen has either:

   void main ()
   {
     ...lots of code...
     glutMainLoop () ;
   }

...or...

   int main ()
   {
     ...lots of code...
     glutMainLoop () ;
     return 0 ;   /* This never happens but keeps the compiler happy */
   }

> At the moment I will go for option (1) simply because I don't know how to
> implement the other two.  I would appreciate any feedback on this.

I agree - (1) may not be ideal for Windoze users - but I think it's
what GLUT normally does.  Just so long as we don't clobber atexit or
on_exit (as GLUT once did), we have left the application with a way
to clean up.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://www.sjbaker.org