#40 Action on Window Close
I have the freeglut-2.2.0 package, so my file/line
number references pertain to that package.
I tried using the glutSetOption function to set the
GLUT_ACTION_ON_WINDOW_CLOSE option to
GLUT_ACTION_CONTINUE_EXECUTION, but when I ran my
program, it still quit when i closed one window. I
poked around a little in the freeglut source, and think
I've tracked down the problem. At the end of
glutMainLoop, there are a couple lines
(lines 1126-1128 in freeglut_main.c)
fgDeinitialize();
if( fgState.ActionOnWindowClose == GLUT_ACTION_EXIT)
exit(0);
The problem is that fgDeinitialize sets
fg.ActionOnWindowClose = GLUT_ACTION_EXIT
on line 271 of freeglut_init.c. So, freeglut always
exits, even if thats not what the user wanted.
This is my first bug report, so I'm not sure if I'm
supposed to make suggestions. Also, this is about as
much as I know about the whole structure of the
freeglut system, so I dont want to mess anything up. It
seems that a quick thing to do to fix the problem would
be right before fgDeinitialize() on line 1126 of
freeglut_main.c, set a boolean flag
flag = (fgState.ActionOnWindowClose == GLUT_ACTION_EXIT);
and then change the
if(fgState.ActionOnWindowClose == GLUT_ACTION_EXIT)
to
if(flag)
I'm not sure if this is the best solution, but it seems
it should work. Thanks.
Logged In: YES
user_id=1004847
Even with that solution, the behavior is still to close all
of the windows once one is closed, and just to drop out of
glutMainLoop, instead of exit(0), when a window is closed
and the GLUT_ACTION_ON_WINDOW_CLOSE is
GLUT_ACTION_CONTINUE_EXECUTION. This seems unsatisfying to
me, in that I'd want a program to run until all of the
windows have been closed. How could this be rigged up? Why
is this not the behavior? Thanks for anybody's advice.
Logged In: YES
user_id=854844
First: The suggestion that you made above was done some
time ago. Always (ALWAYS) use the *latest* version of
software, if you can, to test bugs prior to filing reports.
This is not the first time that a problem was more or less
addressed before anyone got around to writing a formal bug
report. (^&
Usually "the latest version" that you can test is *not*
a release version. Many open source projects use CVS to
synchromize developer efforts. Additionally, OpenGLUT
provides a nightly tarball
The reason that what you ask for is not the normal behavior,
I think, is because freeglut is heavily geared towards doing
exactly what old GLUT did, right or wrong. Old GLUT did not
offer any way to handle windows closing (it just exited
immediately). This was presumably to keep life simple for
writing simple demonstrations of graphics programming.
Adhering to GLUT's conventions keeps freeglut from always
doing the most convenient or useful things. You might need
to look to another member of the GLUT family to satisfy
your needs.
Logged In: YES
user_id=1004847
I do apologize. I should probably just leave everybody alone
:) Thanks rkrolib for setting me straight.
Logged In: YES
user_id=854844
No, you've found a bug I think, still.
Logged In: YES
user_id=854844
This has been fixed in OpenGLUT.
John Fay seems to agree that this is a bug in freeglut, so
it may get fixed.
Logged In: YES
user_id=1132404
I found the same thing, and a similar fix.
So I moved the call to fgDeinitialize() to after the test
of fgState.ActionOnWindowClose
Logged In: YES
user_id=504851
BOINC (a big open-source project for SETI@HOME et.al) is
using 'classic' glut at the moment, and the exit-behaviour
is giving a lot of headaches.
I was just considering switching it to freeglut, which
claims to solve this problem, and found it didn't work (in
the latest release-2.2), as described in this bug-report.
Now, I checked the cvs, and it seems this bug was fixed in
version1.85 of glut_main.c, around a month after the last
stable release, and this was about a year ago!
One of the *main-features* of freeglut IMHO, which fixes one
of the gravest annoyances with glut, is actually STILL
broken in the latest stable release....!! even though a
bug-fix has been committed to CVS for about a year now!!!???
Why has there been no new release since then?
The conclusion right now seems to me that I can't suggest to
move BOINC to use freeglut, because the latest release is
actually just as broken as glut in that respect... :(
Logged In: YES
user_id=854844
Two bits of good news:
* OpenGLUT has had numerous releases and includes fixes
to this and other problems. I believe that freeglut's
fix for this was just an import of the OpenGLUT fix,
which unfortunately was not credited as such.
* freeglut may be gearing up for a new release, again,
after more than a year in the closet.
One thing to beware of is that Steve Baker, the project
admin for freeglut, has repeatedly said that he does not
believe that GLUT should be used for new programs and
resists new features for freeglut. Steve Baker is welcome
to his opinions, but does not speak for non-freeglut
GLUT projects such as OpenGLUT. OpenGLUT and freeglut
are *not* competitors, since OpenGLUT installs with
different headers and library names (though the API is
essentially the same). OpenGLUT also includes man-pages,
but since freeglut does not, there is no conflict there
either.
Full disclosure: I have put many, many hours into both
libraries. I'd like to see both prosper for their
respective niches. freeglut sets its goal as being a
drop-in for old GLUT. OpenGLUT set its goal to be
useful for new projects. I encourage people to install
both (and, myself, I keep Kilgard's GLUT installed as
well, since there are some things that old GLUT does better
than either freeglut or OpenGLUT).
Logged In: YES
user_id=70811
Originator: NO
This appears to have been fixed. If it is still a problem, please open a new bug report.
John Fay indicated this appeared to be fixed. Double checking, I can confirm the ActionOnWindowClose variable is not changed before testing it's value.