A perfectly reasonable stance.

I've actually got two extensions already.  I've already described the first.  The second addresses an outstanding issue on the sourceforge site, #1647258, but only on the Windows side for now.  On that one, freeglut is swallowing keypresses rather than letting DefWindowProc do its thing, so standard keystrokes are ignored, like "Alt+F4" (Close) or "Alt+Space" (Open System Menu).  To work around this, I added checks in the appropriate spots of fgWindowProc, a flag to SFG_Window, and a window option function, glutSetWindowOption.

What is the correct process in this sandbox for working these patches into the trunk?  I can do an svn diff easily enough and send an email to this list, but if there's a better process, let me know and I'll comply.

As for naming, I was rather proud of the glutton moniker, but I'd rather avoid forking.  Should I drop the #ifdef's and just consider it a straight patch, or...?

-- Early

On Jan 13, 2008 5:20 PM, Steve Baker <steve@sjbaker.org> wrote:
I don't think we have an interest in someone gluing their set of
extensions inside freeglut with another name.  Either we accept (on
a case-by-case basis) individual changes and they become a full,
first-class part of the APU - or you fork and do whatever you like,
but hopefully do not tell people that what you are distributing is
"freeglut" because that would cause horrible confusion.

Generally, I regard freeglut as "finished except for bugfixes" - but
your extension doesn't seem too terrible (given that we already have
an extension that does similar things - and presuming your extension
to that wouldn't impact existing programs in any way.

But I must emphasise that we'd want to take your changes on a
case-by-case basis.

  -- Steve.


Early Ehlinger wrote:
> Hello all,
>
> I'm in the process of writing a cross-platform GUI application based on
> freeglut, and have come across some shortcomings that I intend to
> address with a set of extensions which I'm calling the "glutton"
> extensions.
>
> The first such extension has to do with the behavior of glut when the
> user clicks the "x" button.  I've noticed the options regarding what to
> do /after/ the window closes (exit immediately, a la normal glut,
> continue processing, etc), but there doesn't seem to be any existing
> hook for determining whether the window should close at all.  If your
> window represents a file that has been modified, for example, normal GUI
> conventions suggest that you should first ask the user if they want to
> save their changes, cancel, etc.  But glut and freeglut offer no such
> capability as far as I can see.
>
> Adding the ability for freeglut to call back when the user clicks the
> "X" is fairly easy with a small patch to freeglut, at least on Windows.
> On "X", I know it's possible (using IPCC, if I recall), but I haven't
> begun to look into how to do it in the context of freeglut just yet.
>
> As part of this process, I'm also creating VC++ 2008 Express workspaces
> since it's free (as in beer), and much more up-to-date than VC 6.0.
>
> My questions are:
>
> 1) Am I re-inventing the wheel as far as freeglut is concerned?  Is this
> extension already there, and I'm just missing it?
>
> 2) Is there interest in the freeglut community in having these changes
> in the trunk, or should I fork my glutton extensions off now?
>
> 3) If there is interest, the convention I've come up with for adding
> these extensions is something like what I describe below.  Please
> provide concerns, comments, and suggestions.
>
> * The default behavior for any extension should be to work as though the
> extension were not present.  That is, to behave as freeglut would
> without the extension, or as glut would.  I.e., no glutton extension
> should break existing code.
>
> * Any API's added for glutton should use the glutton prefix rather than
> the glut prefix to make them readily identifiable and easily avoided for
> developers wishing to remain code-compatible with glut.
>
> * All glutton modifications shall be wrapped in #ifdef GLUTTON blocks so
> that they can easily be turned off.
>
> By way of example, this is how my first extension looks:
>
> in freeglut_ext.h:
>
> #ifdef GLUTTON
> /*
>  * Sets the CloseRequested callback for the current window
>  * The callback is of the form void CloseRequestedFunc( int* Action )
>  * On entry to the callback, *Action will be set to 1
>  * On exit, its value will control how freeglut with the glutton
>  * extensions reacts to a window close request:
>  *     1 - default behavior (close the window)
>  *     2 - ignore request (e.g., if during the callback your program
> determines that
>  *                         it shouldn't close, like if you show a
> confirmation dialog
>  *                         and the user cancels.)
>  * TODO: replace magic numbers (1&2) with enum values.
>  */
> FGAPI void    FGAPIENTRY gluttonCloseRequestedFunc( void (* callback)(
> int* ) );
> #endif
>
> -- Early
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeglut-developer mailing list
> Freeglut-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freeglut-developer


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Freeglut-developer mailing list
Freeglut-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freeglut-developer