By the way, do we want freeglut's default behavior when the user clicks on
an "x" to be to kill the program?
John F. Fay
john.fay@...
<snip>
------------------------------------------------
- FEATURE: Close callback function for each window
DESCRIPTION:
To avoid the annoying GLUT behavior of closing the whole application when
accidentally clicking onto the close button of any open GLUT-window, a
per-
window callback has been implemented that delegates the decision on what
to
do to the application.
Example:
void myCloseFunc() { exit(3); }
glutCloseFunc(myCloseFunc);
<emphasis>
The default behavior if no close callback is specified is to exit the
application (as it was before).
</emphasis>
NOTE: this is similar to the exitFunc from GLUT 3.7.3, but with more
control
and visible to the application.
------------------------------------------------
<snip>

On Wed, 23 Oct 2002 jim@... wrote:
> I'd suggest supporting both through a set of
> defines in a configuration header file. This
> behavior is a common complaint about GLUT. The
> close window callback is also very common. I think
> most folks would prefer these options be easily
> available.
I disagree that it should be in a configuration header.
GLUT is a system level library and as such, you would'nt
want it to have to be specially compiled for specific
applications.
Either:
* All existing applications can cope with the modified
freeglut behavior -- In which case it can be permenantly
turned on - and doesn't need to be configurable.
OR:
* There are existing applications the will break with the
modified behaviour -- In which case allowing it to be
configured at build time will result in existing applications
breaking when you build GLUT in the 'new' way.
If the former is the case then we might as well have the
default behavior be to return from glutMainLoop when you
hit the window close icon - no need for a compilation option.
If the latter is the case then it's too dangerous to leave
modified versions of freeglut lying around where a sensitive
App might pick them up by mistake - so we have to have the
default behavior be the GLUT behavior and *new* applications
that want the new behavior can just call the destruction
callback - or set a flag that means "Don't Exit when the user
hits 'X'".
I think the latter is nicer/safer because there are a bazillion
GLUT apps out there and we don't know how they all work.
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

Under Win32 this is not the appropriate way to handle shutting down.
Especially
when the library is being used in an embedded environment. Although this
is the way GLUT has always handled it. Unfortunately, to fix this, you
would
have to change the behavior of glutMainLoop so that it returns.. which
is
not part of the GLUT spec. I believe to address this Kilgard added a
"atexit hack"
callback which should be in freeglut as well.. (?)
Regards,
Jim
-----Original Message-----
From: freeglut-developer-admin@...
[mailto:freeglut-developer-admin@...] On Behalf Of Fay
John F Contr AAC/WMG
Sent: Wednesday, October 23, 2002 11:48 AM
To: freeglut-developer@...
Subject: RE: [Freeglut-developer] RE: Window Destruction Callback
Let me apologize right away for my ignorance. Is it okay just to call
"exit ( 0 )" from the middle of the windowing callback where we find
that the user has clicked on the "x"?
John F. Fay
john.fay@...
-----Original Message-----
From: Stephen J Baker [mailto:sjbaker@...]
Sent: Wednesday, October 23, 2002 11:13 AM
To: Fay John F Contr AAC/WMG
Cc: freeglut-developer@...
Subject: RE: [Freeglut-developer] RE: Window Destruction Callback
On Wed, 23 Oct 2002, Fay John F Contr AAC/WMG wrote:
> By the way, do we want freeglut's default behavior when the user
clicks on
> an "x" to be to kill the program?
Yes.
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

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.) And I agree
that we don't need a configuration file for this.
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.
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.
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.
(2) Come back to "glutMainLoop" to allow windows and their contents
the chance to close up shop gracefully, then call "exit" from
"glutMainLoop".
(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.
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.
John F. Fay
john.fay@...
-----Original Message-----
From: Stephen J Baker [mailto:sjbaker@...]
Sent: Wednesday, October 23, 2002 12:58 PM
To: jim@...
Cc: freeglut-developer@...
Subject: RE: [Freeglut-developer] RE: Window Destruction Callback
On Wed, 23 Oct 2002 jim@... wrote:
> I'd suggest supporting both through a set of
> defines in a configuration header file. This
> behavior is a common complaint about GLUT. The
> close window callback is also very common. I think
> most folks would prefer these options be easily
> available.
I disagree that it should be in a configuration header.
GLUT is a system level library and as such, you would'nt
want it to have to be specially compiled for specific
applications.
Either:
* All existing applications can cope with the modified
freeglut behavior -- In which case it can be permenantly
turned on - and doesn't need to be configurable.
OR:
* There are existing applications the will break with the
modified behaviour -- In which case allowing it to be
configured at build time will result in existing applications
breaking when you build GLUT in the 'new' way.
If the former is the case then we might as well have the
default behavior be to return from glutMainLoop when you
hit the window close icon - no need for a compilation option.
If the latter is the case then it's too dangerous to leave
modified versions of freeglut lying around where a sensitive
App might pick them up by mistake - so we have to have the
default behavior be the GLUT behavior and *new* applications
that want the new behavior can just call the destruction
callback - or set a flag that means "Don't Exit when the user
hits 'X'".
I think the latter is nicer/safer because there are a bazillion
GLUT apps out there and we don't know how they all work.
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
Freeglut-developer mailing list
Freeglut-developer@...
https://lists.sourceforge.net/lists/listinfo/freeglut-developer

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: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

> > Steve has suggested a third behavior, by which the
> application can set a
> > "do not exit on 'x' click" flag. This also is compatible
> with default GLUT
> > behavior 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.
I'd suggest a more general,
glutSetOption( optionflag, value )
so that you can re-use this in other future cases. You also might
call it something that implies it's a GLUT extension:
glutSetOptionEx( optionflag, value )
> > 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 Windows 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.
Hmmmm. [I will not be tempted into a platform warz thread.. I will not
be tempted into....]
The truth is, most resources like memory allocation are cleaned up
in Windows if the application is stand-alone. I will say this
however, in most programming books I've read, it is "good form" to
free resources you allocate and not rely on the underlying system
to do it for you. e.g. every malloc has a free, etc..
Certain things under Windows do not get cleaned up because they rely on
3rd party software, e.g. video drivers. When GLUT exits, it should call
code similar to the following for Win32:
void cleanupGlutsMess( void )
{
static char *classname = "GLUT";
HINSTANCE hInstance;
GLUTtimer *tList;
char buf[256];
int i;
i = 0;
if ( __glutWindowListSize > 0 )
{
glEnd();
glFinish();
glFlush();
for (i = 0; i < __glutWindowListSize; i++)
{
if (__glutWindowList[i])
{
glutDestroyWindow(i+1);
}
}
}
/* these are pointers to external handles */
__glutWindowListSize = 0;
__glutStaleWindowList = NULL;
__glutWindowList = NULL;
__glutCurrentWindow = NULL;
/* make sure we no longer have a GL context */
if ( wglGetCurrentContext() != NULL )
{
wglDeleteContext( wglGetCurrentContext() );
}
hInstance = GetModuleHandle(NULL);
UnregisterClass( classname, hInstance );
/* clean up allocated timer memory */
tList = __glutTimerList;
i = 0;
while ( __glutTimerList )
{
i++;
tList = __glutTimerList;
if ( __glutTimerList )
__glutTimerList = __glutTimerList->next;
if ( tList )
free( tList );
}
}
The call to UnregisterClass is extremely important, as a number of
video drivers do not free their GL resources until the window class
has been destroyed. This is one of the main reasons GLUT applications
have so many problems on Win32. Which is one of the reasons why OpenGL
has lost so much popularity on Win32.. it is perceived as being
unreliable. I'd suggest NOT repeating the same mistake with Freeglut,
if you are at all concerned about OpenGL's reliability on ~94% of the
worlds desktops.
Regards,
Jim

jim@... wrote:
steve wrote:
>>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.
>
> I'd suggest a more general,
>
> glutSetOption( optionflag, value )
>
> so that you can re-use this in other future cases. You also might
> call it something that implies it's a GLUT extension:
Yes - that's an excellent proposal - I like it.
> glutSetOptionEx( optionflag, value )
glutSetOptionEXT would be more OpenGL-like.
> The truth is, most resources like memory allocation are cleaned up
> in Windows if the application is stand-alone. I will say this
> however, in most programming books I've read, it is "good form" to
> free resources you allocate and not rely on the underlying system
> to do it for you. e.g. every malloc has a free, etc..
Well - perhaps - but relying on the application to clean up is a major
cause of instability and lack of security in Windoze - I'd rather the OS
did it...and if you really want to do it yourself first, you can.
But as you say - we aren't here to argue the relative merits of OS's -
merely to figure out how to make freeglut cope with the Windoze
requirements for good or for evil.
> The call to UnregisterClass is extremely important, as a number of
> video drivers do not free their GL resources until the window class
> has been destroyed. This is one of the main reasons GLUT applications
> have so many problems on Win32. Which is one of the reasons why OpenGL
> has lost so much popularity on Win32..
...and why Win32 has lost so much popularity amongst OpenGL users! :-)
> it is perceived as being
> unreliable. I'd suggest NOT repeating the same mistake with Freeglut,
> if you are at all concerned about OpenGL's reliability on ~94% of the
> worlds desktops.
Yep - well, as with all OpenSource projects, if someone contributes the
good fixes, we'll be able to adopt them. I don't use Windoze machines
so it certainly me that does that.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@...> WorkEmail: <sjbaker@...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.nethttp://tuxaqfh.sf.nethttp://tuxkart.sf.nethttp://prettypoly.sf.net

A couple more details:
- What do I call the option flag in the "glutSetOption" ? At the
moment I have "GLUT_ACTION_ON_EXIT" but I don't really like it because I
don't think it's quite accurate.
- What numerical value do I give this option flag? For existing
enumerations see "freeglut.h" lines 185-270 (more-or-less). Again for the
moment I am using 0x1F9 for want of something better but I am very much open
to suggestions.
- What do I name the "glutSetOption" function? There are three
contenders so far:
glutSetOption
glutSetOptionEx
glutSetOptionEXT
While I realize that this is an extension to the original GLUT API, I
believe that if we do this right we will become the new GLUT and our API
will simply become a new version rather than an extension. So I have a
preference for the first one. But since I am still thoroughly new to this I
will defer to others.
Speaking of versions of the GLUT API, I notice in "freeglut.h" a
mention of the GLUT API version 4. Does anybody have a copy of this that he
can send me?
Also, are we allowed to use Mark Kilgard's GLUT API document as a
starting point for our own document? Or do we need to start documentation
from scratch?
John F. Fay
john.fay@...
-----Original Message-----
From: Steve Baker [mailto:sjbaker1@...]
Sent: Wednesday, October 23, 2002 5:57 PM
To: jim@...
Cc: freeglut-developer@...
Subject: Re: [Freeglut-developer] RE: Window Destruction Callback
jim@... wrote:
steve wrote:
>>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.
>
> I'd suggest a more general,
>
> glutSetOption( optionflag, value )
>
> so that you can re-use this in other future cases. You also might
> call it something that implies it's a GLUT extension:
Yes - that's an excellent proposal - I like it.
> glutSetOptionEx( optionflag, value )
glutSetOptionEXT would be more OpenGL-like.
<snip>

On Thu, 24 Oct 2002, Fay John F Contr AAC/WMG wrote:
> - What do I call the option flag in the "glutSetOption" ? At the
> moment I have "GLUT_ACTION_ON_EXIT" but I don't really like it because I
> don't think it's quite accurate.
It's not the action on exit - because you are specifically providing
an option to *NOT* exit!
glutSetOptionEXT ( GLUT_ACTION_ON_EXIT, GLUT_DONT_EXIT ) ;
...seems kinda silly!
I think the token should be something like:
GLUT_ACTION_ON_LAST_WINDOW_CLOSE
...which can be set to either:
GLUT_ACTION_EXIT -- The default.
GLUT_ACTION_GLUTMAINLOOP_RETURNS
...it's long - but you aren't going to type it more than
once in a program - so who cares?
> - What numerical value do I give this option flag? For existing
> enumerations see "freeglut.h" lines 185-270 (more-or-less). Again for the
> moment I am using 0x1F9 for want of something better but I am very much open
> to suggestions.
It's nice to keep them unique from existing GLUT tokens - but it's
not essential. I suppose we should pick something higher up in the
number range so that if GLUT 3.8 or 4.0 ever appears, Mark Kilgard
won't happen to pick numbers that collide with ours for any new feature
he picks.
> - What do I name the "glutSetOption" function? There are three
> contenders so far:
> glutSetOption
> glutSetOptionEx
> glutSetOptionEXT
> While I realize that this is an extension to the original GLUT API, I
> believe that if we do this right we will become the new GLUT and our API
> will simply become a new version rather than an extension. So I have a
> preference for the first one. But since I am still thoroughly new to this I
> will defer to others.
The normal OpenGL way to handle this is to start off using the EXT
extension - and then, when every implementation has it, provide a
duplicate function without the EXT part.
The 'glutSetOptionEx' version is a poor choice IMHO. All OpenGL extensions
have the suffix in uppercase - and it's either:
ARB -- An extension defined and officially blessed by the
OpenGL ARB. There is a strong implication that this
will not be optional in some future OpenGL release.
EXT -- A general extension that a lot of people developed but
which isn't (yet) blessed by the ARB for a future release.
NV -- An nVidia extension.
ATI -- An ATI extension.
MESA -- A Mesa extension.
IBM, HP, SGI, SGIS -- ...etc...
...of those, only EXT is appropriate since we are not the OpenGL ARB
(or even the "GLUT ARB" !!) - and we don't have a company name. I
suppose you could argue for FREEGLUT or FG or something.
Some OpenGL extensions started out as NV or SGI, changed to EXT and
then to ARB before finally making it into the OpenGL spec. Often they
change subtly between each incarnation of the extension.
Hence, we have three different texture compression extensions,
four different texture env combine extensions and three different
texture shader extensions - all available on the same set of
drivers for nVidia hardware!
> Speaking of versions of the GLUT API, I notice in "freeglut.h" a
> mention of the GLUT API version 4. Does anybody have a copy of this that he
> can send me?
You already have it!
If you look in /usr/include/GL/glut.h (the original one - not the freeglut one)
you'll see a comment that says:
GLUT_API_VERSION=4 glutInitDisplayString, glutWarpPointer,
glutBitmapLength, glutStrokeLength, glutWindowStatusFunc, dynamic
video resize subAPI, glutPostWindowRedisplay, glutKeyboardUpFunc,
glutSpecialUpFunc, glutIgnoreKeyRepeat, glutSetKeyRepeat,
glutJoystickFunc, glutForceJoystickFunc (NOT FINALIZED!).
...then:
#ifndef GLUT_API_VERSION /* allow this to be overriden */
#define GLUT_API_VERSION 3
#endif
The definition of (for example) the Joystick API is like this:
#if (GLUT_API_VERSION >= 4 || GLUT_XLIB_IMPLEMENTATION >= 13)
extern void APIENTRY glutKeyboardUpFunc( ...
extern void APIENTRY glutSpecialUpFunc( ...
extern void APIENTRY glutJoystickFunc( ...
#endif
...so it seems that these functions were slated for addition in the
future but put into GLUT 3.7 in an undocumented/unsupported form.
However, the definition of GLUT_XLIB_IMPLEMENTATION is 13 (for all
OS's) so those GLUT_API_VERSION==4 definitions are enabled everywhere.
There is no mention of the keyboard 'up' functions or the joystick
API in the official GLUT documentation. Since Mark abandoned work
on GLUT without ever releasing 4.0, these functions are in limbo.
They exist in GLUT 3.7, they work - but not on all platforms - they
aren't documented - but everyone uses them. There isn't a GLUT 4.0
(and probably never will be).
That was back in 1998.
Shortly after freeglut hit the streets in January 2000, several
people claimed to have heard that Mark was close to releasing a
new version of GLUT - with a VASTLY increased feature set. However,
nearly three years later there is still no sign of it so we can only
assume that this was apocryphal.
There have been less than a dozen messages posted to the GLUT mailing
list over the past four or five years since the release of GLUT 3.7.
I answered them all - Mark doesn't seem to be subscribed.
These are the kinds of reasons why we NEED 'freeglut' if we want there
to be a 'GLUT' that works into the future.
> Also, are we allowed to use Mark Kilgard's GLUT API document as a
> starting point for our own document? Or do we need to start documentation
> from scratch?
Mark still owns the copyright on everything he wrote - and his vague
statement of rights is not enough to convince me that we can do
ANYTHING with his code or documents other than redistribute them
verbatim.
It seems a shame to re-document the whole thing though.
I guess we could redistribute his document WITHOUT CHANGES and
write a wrapper document that says: "Refer to Mark's document
<click here> for everything except...glutSetOptionsEXT...etc"
...so we'd only document the changes that are in freeglut.
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

Sorry about the multiple e-mails, but questions come up as I go along.
Do we want the "glutSetOption ( GLenum option_flag, int value )" function to
be able to set (almost) anything that "glutGet" can get? This will allow,
for example, the programmer to reshape his window without calling
"glutReshapeWindow".
Obviously there are some things like screen height and width which we can't
set. But there are others which could go either way.
John F. Fay
john.fay@...

On Thu, 24 Oct 2002, Fay John F Contr AAC/WMG wrote:
> Sorry about the multiple e-mails, but questions come up as I go along.
>
> Do we want the "glutSetOption ( GLenum option_flag, int value )" function to
> be able to set (almost) anything that "glutGet" can get? This will allow,
> for example, the programmer to reshape his window without calling
> "glutReshapeWindow".
Hmmm - I guess so. It would be likely that we'd get duplicate functionality
with other mechanisms that set some of those things - but that wouldn't
hurt.
I think this is a good idea - but only if you feel like implementing
it. I don't think it's *necessary*.
> Obviously there are some things like screen height and width which we can't
> set. But there are others which could go either way.
Indeed.
There is a recent extension to X called (IIRC) "RandR" that allows
you to change the screen resolution on the fly - and I bet MS-Windoze
already has something like that.
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

Here is my latest cut at the window-closing issue. The files aren't on CVS
yet ... and my latest files exist only on my disk. I want to hear what
other people say before I inflict them on the community.
(1) There are now three defined constants in "freeglut.h":
#define GLUT_ACTION_EXIT 0
#define GLUT_ACTION_GLUTMAINLOOP_RETURNS 1
#define GLUT_ACTION_CONTINUE_EXECUTION 2
There is also a variable in the "fgState" structure called
"ActionOnWindowClose", whose default value is GLUT_ACTION_EXIT.
(2) There is a new interface function "glutSetOption" by which the
programmer can change the value of "ActionOnWindowClose" and a new option in
"glutGet" which allows him to retrieve the current value.
(3) There is a new enumerated variable in "fgState" called "ExecState". Its
allowed values are "GLUT_EXEC_STATE_INIT", "GLUT_EXEC_STATE_RUNNING", and
"GLUT_EXEC_STATE_STOP". The value is ...
- initialized to "INIT" at compile time and in "fgDeinitialize"
- set to "RUNNING" in "glutMainLoop" just before the code enters the
main loop
- set to "STOP" if (1) all windows are closed, (2) there are no new
messages (Win32 version--replacing the "bLoop" variable), or (3) the user
has closed a window by clicking on its "x" (see (5) below).
(4) The "glutMainLoop" code stays in its main loop as long as the
"ExecState" variable keeps the "RUNNING" value.
(5) If the user clicks on the "x" to close a window which is not the last
window open, then
- if the action at window close is "continue execution", execution
continues with the other windows
- otherwise "ExecState" is set to "STOP" and the main loop will stop
at the end of its current iteration.
If the user clicks on the "x" to close the last window, then there will be
no more windows (unless the destroy window callback creates a new one) and
the "ExecState" flag will be set to "STOP" in the main loop because there
are no more windows open.
(6) At the end of the "glutMainLoop" code after the actual main loop itself,
there is a call to "fgCleanUpGlutsMess" which closes any open windows and
(when we get it written completely) do anything else that needs doing.
There is also a call to "fgDeinitialize" which may have some code that we
want to move to "fgCleanUpGlutsMess".
(7) At the end of "glutMainLoop", if the action on window close is "exit",
the program exits. Otherwise it returns control to the calling function.
Please note that GLUT's behaviour, that the application exits immediately,
is no longer supported (although the default behaviour is close enough to
GLUT that nobody should notice anything except a possible improvement.)
Once again, I am open for comments. This is most definitely a work in
progress.
John F. Fay
john.fay@...
-----Original Message-----
From: Stephen J Baker [mailto:sjbaker@...]
Sent: Monday, October 28, 2002 8:20 AM
To: Fay John F Contr AAC/WMG
Subject: RE: [Freeglut-developer] RE: Window Destruction Callback
On Thu, 24 Oct 2002, Fay John F Contr AAC/WMG wrote:
> The primary difference between what you are saying and what I am
> saying is in the question of using the "x" to close windows before the
last
> window. GLUT kills the application, period. And if freeglut is going to
> imitate GLUT, then freeglut needs to kill the application, period. My
> customer doesn't like that--and I don't either--and so I propose the
option
> to continue execution.
Oh - I thought GLUT only killed the application when you 'X'ed the last
window.
OK - then you are right and we need something better than I proposed.
The glutSetOption thingy now needs (IMHO) two enumerations:
* What to do when the LAST window is closed.
* What to do when any other window is closed.
> There are actually three issues at hand.
> (1) Should we have a "destroy function" callback? I think we both agree
> that the answer is yes. It is nice to have for cases when the application
> calls "glutDestroyWindow" and it is absolutely necessary if we are going
to
> allow the user to click on the "x" (on some window which is not the last
> one) and have execution continue.
Yes.
> (2) What should happen when the user clicks on the "x" on a window which
is
> not the last? I see three options: continue execution, close all windows
> and return from the main loop, or exit immediately.
Yes. 'continue execution' meaning - call the destroy function callback,
then destroy the window - then carry on running UNLESS it was the last
window - in which case we need another option:
> I submit that if the user clicks on the "x" in a window which is not
> the last window we should at least allow the option of continuing the
> program execution.
Yes - I'm horrified that this isn't what GLUT does...but then I don't
do much multi-window stuff.
> (3) What should happen when the program closes the last window by any
> method? I agree with you that there are only two options which make
sense:
> return from the main loop or exit immediately. The "glutMainLoop"
function
> will not continue to execute if there are no windows open, so the
"continue
> execution" option turns into "return from the main loop."
I guess so. I was thinking of two separate flags - but once you've
set a flag that GLUT doesn't have, you are already admitting that your
program isn't GLUT-compatible - so it's not unreasonable to say that
glutMainLoop will always return if you select some non-GLUT option
for general window destruction because no existing program can fall
foul of that.
> Actually, I see on reading your e-mail again that I have been
> confusing what are actually two separate options: call "exit" from the
main
> loop, and return from the main loop. I hadn't really considered calling
> "exit" from the main loop because I was thinking that it would be
redundant,
> given that the "exit immediately" option would do some GLUT cleanup. But
> perhaps we should discard the notion of exiting from within the callback
and
> instead make "exit immediately" mean "set a flag, drop out of the main
loop,
> close all the windows in a civilized manner, and then exit."
>
> The only issue of backwards compatibility is, as you say, with the
> option to return from the main loop. And since we are setting the "exit
> immediately" option to be the default, existing applications won't need to
> be changed.
Right.
> There is also another question, which we haven't really taken up
> yet: do we want this window-closing behaviour to be selectable on a
> window-by-window basis, or do we want one behaviour fits all windows?
I'd suggest one-fits-all. If you want your application to exit when
some windows are destroyed (type A) and not others (type B), then
you can handle that by telling freeglut:
1) Don't exit on window destruction - ever.
2) Register a close-window callback for type A windows which closes
all the other windows and thereby triggers the program-exit.
3) Register a close-window callback for type B windows which just
closes that window.
> In my
> fifty-window application, there are four basic windows that I can't live
> without, while the other forty-something come and go. While it would be
> nice to have the behaviour selectable, it's not that important; I can just
> put the "exit" statement in the destroy callback.
Exactly.
In general, the less per-window behavior there is, the easier this
thing will be to understand.
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

Can I just say no.
--
Christopher John Purnell | I thought I'd found a reason to live
http://www.lost.org.uk/ | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands

On Mon, Oct 28, 2002 at 01:31:48PM -0600, Stephen J Baker wrote:
> On Mon, 28 Oct 2002, Chris Purnell wrote:
>
> > Can I just say no.
>
> Of course - but your opinions would carry more weight if you explained
> why.
I just think that when a function is documented as never returning it
should never return.
I also think that providing an alternative entry point for the event
handler that does exit is a much cleaner solution.
But most of all I think we should be concentrating of making freeglut
good enough that I'd consider replacing glut with it before we even
think about API extentions.
I must say at this point that the reason I've not done any work on
freeglut for ages is every time a look at the code I get this urge
to rearange the entire source tree. Including such things as
moving functions from one file to another to make it more static
link frendly.
--
Christopher John Purnell | I thought I'd found a reason to live
http://www.lost.org.uk/ | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands

Chris Purnell wrote:
> On Mon, Oct 28, 2002 at 01:31:48PM -0600, Stephen J Baker wrote:
>
>>On Mon, 28 Oct 2002, Chris Purnell wrote:
>>
>>
>>>Can I just say no.
>>>
>>Of course - but your opinions would carry more weight if you explained
>>why.
>>
>
> I just think that when a function is documented as never returning it
> should never return.
I guess you could say there was a case for having glutMainLoopThatReturns
and glutMainLoop (that doesn't).
Given that this proposal is to leave the default behavior exactly as it
always was - and that you have to specifically ask to change that default,
I don't see that it makes a whole lot of difference.
> I also think that providing an alternative entry point for the event
> handler that does exit is a much cleaner solution.
I guess it's a matter of taste. I don't feel very strongly about it
either way.
> But most of all I think we should be concentrating of making freeglut
> good enough that I'd consider replacing glut with it before we even
> think about API extentions.
Well, this is an OpenSource project - and nobody has offered to do major
cleanup until John picked it up. He who does the majority of the work
gets to make the big decisions.
> I must say at this point that the reason I've not done any work on
> freeglut for ages is every time a look at the code I get this urge
> to rearange the entire source tree. Including such things as
> moving functions from one file to another to make it more static
> link frendly.
Yes - I know what you mean - but I find a terrible desire to rewrite
any code that I didn't write and I know there aren't enough hours in
one lifetime to do that.
So, I havn't attacked freeglut either.
Since John is providing valuable contributions - and nobody else
has, I think we should let him get on with it. If you want to come
along and do cleanup work, that'll also be very welcome...but if you
are doing major rework, it would be wise to ensure that nobody else
is going to be tinkering with it in meantime or else you'll have one
heck of a time merging in your changes. Work with John - from his
excellent work on PLIB/PUI I recommend we let him do his stuff first.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@...> WorkEmail: <sjbaker@...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.nethttp://tuxaqfh.sf.nethttp://tuxkart.sf.nethttp://prettypoly.sf.net

Whoops! We have a compatibility issue.
Since GLUT exits immediately, there are no more callbacks generated when the
user clicks on the "x". If we drop out of the freeglut main loop and then
exit, then the idle callback may easily get called again. (I know this
because I was checking this out with a three-window application and it keeps
crashing.) Without the application defining a window destroy callback,
there is no way for the application to find out that the window has been
closed. So when it tries to render the window in its idle callback, we get
a "window ID %d not found!" warning from freeglut, followed by a program
crash when I call "glutSwapBuffers".
So now it's time for a design decision. Shall we:
(1) make the default behaviour absolutely compatible with GLUT and exit
immediately, or
(2) make the default behaviour clean up after itself and possible break some
GLUT applications?
John F. Fay
john.fay@...
-----Original Message-----
From: Fay John F Contr AAC/WMG
Sent: Monday, October 28, 2002 10:24 AM
To: 'freeglut-developer@...'
Subject: RE: [Freeglut-developer] RE: Window Destruction Callback
Here is my latest cut at the window-closing issue. The files aren't on CVS
yet ... and my latest files exist only on my disk. I want to hear what
other people say before I inflict them on the community.
(1) There are now three defined constants in "freeglut.h":
#define GLUT_ACTION_EXIT 0
#define GLUT_ACTION_GLUTMAINLOOP_RETURNS 1
#define GLUT_ACTION_CONTINUE_EXECUTION 2
There is also a variable in the "fgState" structure called
"ActionOnWindowClose", whose default value is GLUT_ACTION_EXIT.
(2) There is a new interface function "glutSetOption" by which the
programmer can change the value of "ActionOnWindowClose" and a new option in
"glutGet" which allows him to retrieve the current value.
(3) There is a new enumerated variable in "fgState" called "ExecState". Its
allowed values are "GLUT_EXEC_STATE_INIT", "GLUT_EXEC_STATE_RUNNING", and
"GLUT_EXEC_STATE_STOP". The value is ...
- initialized to "INIT" at compile time and in "fgDeinitialize"
- set to "RUNNING" in "glutMainLoop" just before the code enters the
main loop
- set to "STOP" if (1) all windows are closed, (2) there are no new
messages (Win32 version--replacing the "bLoop" variable), or (3) the user
has closed a window by clicking on its "x" (see (5) below).
(4) The "glutMainLoop" code stays in its main loop as long as the
"ExecState" variable keeps the "RUNNING" value.
(5) If the user clicks on the "x" to close a window which is not the last
window open, then
- if the action at window close is "continue execution", execution
continues with the other windows
- otherwise "ExecState" is set to "STOP" and the main loop will stop
at the end of its current iteration.
If the user clicks on the "x" to close the last window, then there will be
no more windows (unless the destroy window callback creates a new one) and
the "ExecState" flag will be set to "STOP" in the main loop because there
are no more windows open.
(6) At the end of the "glutMainLoop" code after the actual main loop itself,
there is a call to "fgCleanUpGlutsMess" which closes any open windows and
(when we get it written completely) do anything else that needs doing.
There is also a call to "fgDeinitialize" which may have some code that we
want to move to "fgCleanUpGlutsMess".
(7) At the end of "glutMainLoop", if the action on window close is "exit",
the program exits. Otherwise it returns control to the calling function.
Please note that GLUT's behaviour, that the application exits immediately,
is no longer supported (although the default behaviour is close enough to
GLUT that nobody should notice anything except a possible improvement.)
Once again, I am open for comments. This is most definitely a work in
progress.
John F. Fay
john.fay@...
-----Original Message-----
From: Stephen J Baker [mailto:sjbaker@...]
Sent: Monday, October 28, 2002 8:20 AM
To: Fay John F Contr AAC/WMG
Subject: RE: [Freeglut-developer] RE: Window Destruction Callback
On Thu, 24 Oct 2002, Fay John F Contr AAC/WMG wrote:
> The primary difference between what you are saying and what I am
> saying is in the question of using the "x" to close windows before the
last
> window. GLUT kills the application, period. And if freeglut is going to
> imitate GLUT, then freeglut needs to kill the application, period. My
> customer doesn't like that--and I don't either--and so I propose the
option
> to continue execution.
Oh - I thought GLUT only killed the application when you 'X'ed the last
window.
OK - then you are right and we need something better than I proposed.
The glutSetOption thingy now needs (IMHO) two enumerations:
* What to do when the LAST window is closed.
* What to do when any other window is closed.
> There are actually three issues at hand.
> (1) Should we have a "destroy function" callback? I think we both agree
> that the answer is yes. It is nice to have for cases when the application
> calls "glutDestroyWindow" and it is absolutely necessary if we are going
to
> allow the user to click on the "x" (on some window which is not the last
> one) and have execution continue.
Yes.
> (2) What should happen when the user clicks on the "x" on a window which
is
> not the last? I see three options: continue execution, close all windows
> and return from the main loop, or exit immediately.
Yes. 'continue execution' meaning - call the destroy function callback,
then destroy the window - then carry on running UNLESS it was the last
window - in which case we need another option:
> I submit that if the user clicks on the "x" in a window which is not
> the last window we should at least allow the option of continuing the
> program execution.
Yes - I'm horrified that this isn't what GLUT does...but then I don't
do much multi-window stuff.
> (3) What should happen when the program closes the last window by any
> method? I agree with you that there are only two options which make
sense:
> return from the main loop or exit immediately. The "glutMainLoop"
function
> will not continue to execute if there are no windows open, so the
"continue
> execution" option turns into "return from the main loop."
I guess so. I was thinking of two separate flags - but once you've
set a flag that GLUT doesn't have, you are already admitting that your
program isn't GLUT-compatible - so it's not unreasonable to say that
glutMainLoop will always return if you select some non-GLUT option
for general window destruction because no existing program can fall
foul of that.
> Actually, I see on reading your e-mail again that I have been
> confusing what are actually two separate options: call "exit" from the
main
> loop, and return from the main loop. I hadn't really considered calling
> "exit" from the main loop because I was thinking that it would be
redundant,
> given that the "exit immediately" option would do some GLUT cleanup. But
> perhaps we should discard the notion of exiting from within the callback
and
> instead make "exit immediately" mean "set a flag, drop out of the main
loop,
> close all the windows in a civilized manner, and then exit."
>
> The only issue of backwards compatibility is, as you say, with the
> option to return from the main loop. And since we are setting the "exit
> immediately" option to be the default, existing applications won't need to
> be changed.
Right.
> There is also another question, which we haven't really taken up
> yet: do we want this window-closing behaviour to be selectable on a
> window-by-window basis, or do we want one behaviour fits all windows?
I'd suggest one-fits-all. If you want your application to exit when
some windows are destroyed (type A) and not others (type B), then
you can handle that by telling freeglut:
1) Don't exit on window destruction - ever.
2) Register a close-window callback for type A windows which closes
all the other windows and thereby triggers the program-exit.
3) Register a close-window callback for type B windows which just
closes that window.
> In my
> fifty-window application, there are four basic windows that I can't live
> without, while the other forty-something come and go. While it would be
> nice to have the behaviour selectable, it's not that important; I can just
> put the "exit" statement in the destroy callback.
Exactly.
In general, the less per-window behavior there is, the easier this
thing will be to understand.
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

On Tue, Oct 29, 2002 at 10:08:00AM -0600, Fay John F Contr AAC/WMG wrote:
> Since GLUT exits immediately, there are no more callbacks generated when the
> user clicks on the "x". If we drop out of the freeglut main loop and then
> exit, then the idle callback may easily get called again. (I know this
> because I was checking this out with a three-window application and it keeps
> crashing.) Without the application defining a window destroy callback,
> there is no way for the application to find out that the window has been
> closed. So when it tries to render the window in its idle callback, we get
> a "window ID %d not found!" warning from freeglut, followed by a program
> crash when I call "glutSwapBuffers".
>
> So now it's time for a design decision. Shall we:
>
> (1) make the default behaviour absolutely compatible with GLUT and exit
> immediately, or
>
> (2) make the default behaviour clean up after itself and possible break some
> GLUT applications?
Rendering to the window in the idle callback is bad practive but people do
it. Which is why glut exits immediatly on a window close button event.
The only other behaviour that does not break stuff is to leave the window
open.
I still say the cleanup function should be registered with atexit().
--
Christopher John Purnell | I thought I'd found a reason to live
http://www.lost.org.uk/ | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands

On Tue, 29 Oct 2002, Chris Purnell wrote:
> On Tue, Oct 29, 2002 at 10:08:00AM -0600, Fay John F Contr AAC/WMG wrote:
>
> > Since GLUT exits immediately, there are no more callbacks generated when the
> > user clicks on the "x". If we drop out of the freeglut main loop and then
> > exit, then the idle callback may easily get called again.
Not if we prevent that. If freeglut has decided that it's going to
return from main-loop because all the windows are closed then it
shouldn't call anymore user callbacks on the way out.
> > I was checking this out with a three-window application and it keeps
> > crashing.) Without the application defining a window destroy callback,
> > there is no way for the application to find out that the window has been
> > closed. So when it tries to render the window in its idle callback, we get
> > a "window ID %d not found!" warning from freeglut, followed by a program
> > crash when I call "glutSwapBuffers".
> >
> > So now it's time for a design decision. Shall we:
> >
> > (1) make the default behaviour absolutely compatible with GLUT and exit
> > immediately, or
That seems the simplest thing - the least likely to break existing apps.
> > (2) make the default behaviour clean up after itself and possible break some
> > GLUT applications?
I don't see a problem with returning from main-loop without calling any
more callbacks along the way. Once you've made the decision to return,
there needn't be any other actions taken.
> Rendering to the window in the idle callback is bad practive but people do
> it.
Yes - they do. :-(
I never understood why though.
> Which is why glut exits immediatly on a window close button event.
> The only other behaviour that does not break stuff is to leave the window
> open.
Why?
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

Registering the cleanup function with "atexit" is a good idea, but it
doesn't address one of my concerns. I have an application with fifty
different windows and I don't want the application to exit when the user
clicks the "x" on most of them. So I need freeglut to support a "continue
execution but close this window" option here. If the idle callback renders
to the window which has just been closed, there is bad news.
There is also a second question about the "atexit" function. If we do go
this way, do we expect the application programmer to write the cleanup
function or is it part of freeglut? And if we decide to make it part of
freeglut, can the user write his own "atexit" function? (I am simply
ignorant here: does "atexit" support multiple callbacks or is it restricted
to one?)
John F. Fay
john.fay@...
-----Original Message-----
From: Chris Purnell [mailto:cjp@...]
Sent: Tuesday, October 29, 2002 11:57 AM
To: freeglut-developer@...
Subject: Re: [Freeglut-developer] RE: Window Destruction Callback
On Tue, Oct 29, 2002 at 10:08:00AM -0600, Fay John F Contr AAC/WMG wrote:
> Since GLUT exits immediately, there are no more callbacks generated when
the
> user clicks on the "x". If we drop out of the freeglut main loop and then
> exit, then the idle callback may easily get called again. (I know this
> because I was checking this out with a three-window application and it
keeps
> crashing.) Without the application defining a window destroy callback,
> there is no way for the application to find out that the window has been
> closed. So when it tries to render the window in its idle callback, we
get
> a "window ID %d not found!" warning from freeglut, followed by a program
> crash when I call "glutSwapBuffers".
>
> So now it's time for a design decision. Shall we:
>
> (1) make the default behaviour absolutely compatible with GLUT and exit
> immediately, or
>
> (2) make the default behaviour clean up after itself and possible break
some
> GLUT applications?
Rendering to the window in the idle callback is bad practive but people do
it. Which is why glut exits immediatly on a window close button event.
The only other behaviour that does not break stuff is to leave the window
open.
I still say the cleanup function should be registered with atexit().
--
Christopher John Purnell | I thought I'd found a reason to live
http://www.lost.org.uk/ | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Freeglut-developer mailing list
Freeglut-developer@...
https://lists.sourceforge.net/lists/listinfo/freeglut-developer