Let me look this over ...

On 1/20/2012 2:02 AM, Diederick C. Niehorster wrote:
Hi John,

See the attached for a splitting of the headers. I have split out
almost all platform specific code, except for some conditional fields
in SFG_Context and SFG_WindowState (defining the whole structures in
the platform specific files seems like too much code repetition) and
the definition of INVOKE_WCB (that looks complicated enough to better
leave it in context).

I had to make some small edits to some of the windows only functions
as they took SFG_Window* as an input, but that hindered declaring the
functions in another header file. Most of these functions where my
own, the exceptions being fgNewWGLCreateContext and
fgSetupPixelFormat. I have changed their inputs slightly to avoid
trouble, and tested this well of course.. no trouble arises!

I have also split off the x11 parts into the x11 headers as I was
going through the files. None of the code there depended on things
actually defined in src\Common\freeglut_internal.h, and thus no
problems should creep up. We'll have to ask a linuxer of course to
have a look whether things still compile fine after you added it to

One last thing, I see a bunch of autoconf references in
freeglut_internal.h. Is that still going to be relevant when we switch
to CMake? Or should that be taken out at some point?


On Fri, Jan 20, 2012 at 13:36, Diederick C. Niehorster
<dcnieho@gmail.com> wrote:
Hi John,

On Fri, Jan 20, 2012 at 12:14, John F. Fay <johnffay@cybertron.com> wrote:
After I raised the question, I thought for a minute and considered the
possibility of including "fgDisplay" as a substructure under
"fgStructure".  But I haven't thought that far ahead yet.
Hmm, we'll have to think about that.

The changes I'm making right now remind me of a description from "the
Hitchhiker's Guide to the Galaxy":  "Like most Vogon ships, this one
looked as if it had not so much been designed as that it had
congealed."  I'm just splitting out the code that splits out easily, in
relatively small chunks, figuring that when (not if, but when) I break
the build it should be relatively simple to go back and see where it
That might be a good plan. But I was thinking we should approach the
internal header file in a more systematic way, just because a change
their reverberates all through the code files, whereas changes in the
c files are relatively isolated, and more amenable to congealing :P
I think we 'd have to think about a good redesign (might actually be
much less involved than it sounds like) of the header files, and then
go more stepwise into splitting out code. But I'm very glad to see
you've kicked us off and got some momentum going. Chinese new year is
coming up, which means that outside of family visits, I should have
some time to really look at this. And I'm looking forward to it.

------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________ Freeglut-developer mailing list Freeglut-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freeglut-developer