#40 Action on Window Close

nuisance (37)

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
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)

if( fgState.ActionOnWindowClose == GLUT_ACTION_EXIT)

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)

I'm not sure if this is the best solution, but it seems
it should work. Thanks.


  • nhamblet

    nhamblet - 2004-04-01

    Logged In: YES

    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
    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.

  • Richard Rauch

    Richard Rauch - 2004-04-20

    Logged In: YES

    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.

  • nhamblet

    nhamblet - 2004-04-20

    Logged In: YES

    I do apologize. I should probably just leave everybody alone
    :) Thanks rkrolib for setting me straight.

  • Richard Rauch

    Richard Rauch - 2004-04-20

    Logged In: YES

    No, you've found a bug I think, still.

  • Richard Rauch

    Richard Rauch - 2004-04-22

    Logged In: YES

    This has been fixed in OpenGLUT.

    John Fay seems to agree that this is a bug in freeglut, so
    it may get fixed.

  • Bernd H Stramm

    Bernd H Stramm - 2005-01-14

    Logged In: YES

    I found the same thing, and a similar fix.
    So I moved the call to fgDeinitialize() to after the test
    of fgState.ActionOnWindowClose

  • Reinhard Prix

    Reinhard Prix - 2005-01-19

    Logged In: YES

    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... :(

  • Richard Rauch

    Richard Rauch - 2005-01-20

    Logged In: YES

    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

    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).

  • John F. Fay

    John F. Fay - 2007-09-29

    Logged In: YES
    Originator: NO

    This appears to have been fixed. If it is still a problem, please open a new bug report.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks