Not to cause any arguments, but I have used both Fltk 1.1 and 2.0 with
freeglut and glut respectively, with no problems. The only issue that I
have is that is seems fltk 2.0 doesn't support the freeglut 3D primitive
drawing (glutSolidTeapot, for example), so I just used glut for it. I
have had no problems whatsover other than keeping track of which library
to use (glut or freeglut). I use my own glut display for drawing, and
it does it inside of Fltk nicely. I have recently switched back to glut
3.7 for simplicity until Fltk 2.0 supports it. Which may be my fault
anyways, but I would get unresolved externals on those primitive drawing
declarations if I try to use them while linking with freeglut.
Just my 2 cents.
Sincerely,
Lee
=20
-----Original Message-----
From: freeglut-bugs-bounces@...
[mailto:freeglut-bugs-bounces@...] On Behalf Of Henrik
R. Nagel
Sent: Tuesday, October 23, 2007 3:36 AM
To: Steve Baker
Cc: freeglut-bugs@...
Subject: Re: [Freeglut-bugs] Incompatibility with FLTK
Hi,
Steve Baker wrote:
> This is a very serious error - we rely on the application calling
that=20
> function before getting started so we can initialise our internal=20
> state. Without glutInit - the program could easily crash and burn in=20
> all sorts of exciting and unexpected ways later on. We are right to=20
> treat it as an error and you should be more interested in fixing your=20
> real problem than in bitching to us!
I strongly dislike your attitude. You must have a terrible personality.
The following is a quote from FLTK's manual:
"Mixing GLUT and FLTK Code
You can make your GLUT window a child of a Fl_Window with the following=20
scheme. The biggest trick is that GLUT insists on show() 'ing the window
at the point it is created, which means the Fl_Window parent window must
already be shown.
* Don't call glutInit().
* Create your Fl_Window, and any FLTK widgets. Leave a blank area=20
in the window for your GLUT window.
* show() the Fl_Window. Perhaps call show(argc,argv).
* Call window->begin() so that the GLUT window will be=20
automatically added to it.
* Use glutInitWindowSize() and glutInitWindowPosition() to set the=20
location in the parent window to put the GLUT window.
* Put your GLUT code next. It probably does not need many changes.=20
Call window->end() immediately after the glutCreateWindow()!
* You can call either glutMainLoop(), Fl::run(), or loop calling=20
Fl::wait() to run the program."
Notice the "Don't call glutInit()" statement.
Perhaps you could talk directly to the people behind the otherwise=20
excellent FLTK about how you two groups can make your software=20
compatible with each other. I can't be the only one that uses both=20
software packages and I certainly won't be the last.
Best regards,
Henrik
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Freeglut-bugs mailing list
Freeglut-bugs@...
https://lists.sourceforge.net/lists/listinfo/freeglut-bugs

Hi,
Steve Baker wrote:
> This is a very serious error - we rely on the application calling that
> function before getting started so we can initialise our internal
> state. Without glutInit - the program could easily crash and burn in
> all sorts of exciting and unexpected ways later on. We are right to
> treat it as an error and you should be more interested in fixing your
> real problem than in bitching to us!
I strongly dislike your attitude. You must have a terrible personality.
The following is a quote from FLTK's manual:
"Mixing GLUT and FLTK Code
You can make your GLUT window a child of a Fl_Window with the following
scheme. The biggest trick is that GLUT insists on show() 'ing the window
at the point it is created, which means the Fl_Window parent window must
already be shown.
* Don't call glutInit().
* Create your Fl_Window, and any FLTK widgets. Leave a blank area
in the window for your GLUT window.
* show() the Fl_Window. Perhaps call show(argc,argv).
* Call window->begin() so that the GLUT window will be
automatically added to it.
* Use glutInitWindowSize() and glutInitWindowPosition() to set the
location in the parent window to put the GLUT window.
* Put your GLUT code next. It probably does not need many changes.
Call window->end() immediately after the glutCreateWindow()!
* You can call either glutMainLoop(), Fl::run(), or loop calling
Fl::wait() to run the program."
Notice the "Don't call glutInit()" statement.
Perhaps you could talk directly to the people behind the otherwise
excellent FLTK about how you two groups can make your software
compatible with each other. I can't be the only one that uses both
software packages and I certainly won't be the last.
Best regards,
Henrik

Henrik R. Nagel wrote:
> Hi,
>
> I have made an OpenGL program using FLTK. The user of the program has
> Ubuntu installed, which, apparently, only provides freeglut and not the
> old version of glut, which I uses. When the program is run, the
> following error message appears:
>
> freeglut ERROR: Function <glutStrokeLength> called without first
> calling 'glutInit'
>
> This error obviously comes from the call to
> FREEGLUT_EXIT_IF_NOT_INITIALISED() in glutStrokeLength().
>
> Must you absolutely check for this at every single frame during the
> entire execution of a program?
>
We don't.
If you are getting this message then the program can never have called
glutInit - which is flat out illegal in either GLUT or freeglut.
(Possibly GLUT fails to detect this error - but it's still an error -
the manual clearly states that 'glutInit' has to be the very first GLUT
call you make - and if you are seeing this error then you are illegally
calling glutStrokeLength before glutInit - and that's not something
that's supported by either GLUT or freeglut).
This is a very serious error - we rely on the application calling that
function before getting started so we can initialise our internal
state. Without glutInit - the program could easily crash and burn in
all sorts of exciting and unexpected ways later on. We are right to
treat it as an error and you should be more interested in fixing your
real problem than in bitching to us!
HOWEVER:
If the macro 'FREEGLUT_EXIT_IF_NOT_INITIALISED' finds that the package
isn't initialised then it calls 'fgError()' which in turn calls exit(1)
to exit the program - this should cause your program to die (as indeed
it deserves) - so the message shouldn't have come out more than once.
If you're seeing it "every frame", then that would mean that it wasn't
exiting - I don't understand how that could be. Pretty much all of the
GLUT calls make that exact same check - so even if someone hacked the
code to somehow not exit - you'd be getting complaints from every other
GLUT call you make prior to glutInit - and then no more after that. So
I guess we have to deduce that perhaps this is running in some kind of a
parallel execution thread that's being respawned whenever it exits? If
so, then that's the reason your getting the message over and over - not
that we are triggering it "every frame" (which we do not).
freeglut is absolutely right to make a damned nuisance of itself!
Turning off the error message would be an extremely amateurish way to
work around a serious application problem that needs to be fixed.
Failing to call glutInit() would mean that your program would misbehave
in much, MUCH harder to diagnose ways. This error message is doing you
a favor - you should be grateful we put it there for you.
Steve.

Hi,
I have made an OpenGL program using FLTK. The user of the program has
Ubuntu installed, which, apparently, only provides freeglut and not the
old version of glut, which I uses. When the program is run, the
following error message appears:
freeglut ERROR: Function <glutStrokeLength> called without first
calling 'glutInit'
This error obviously comes from the call to
FREEGLUT_EXIT_IF_NOT_INITIALISED() in glutStrokeLength().
Must you absolutely check for this at every single frame during the
entire execution of a program?
In my program, I have statements like this:
#ifdef DEBUG
if (column >= maxNumberOfColumns)
...
#endif
for handling rarely occurring errors, that do not depend on the input
data of a program. When developing, DEBUG is always defined, but when a
program is working correctly, I can make an optimized version of it
without this code. The point is that I thereby can insert these kinds of
checks all over the code, without being concerned with the program
slowing down. In your case, you could provide two libraries optim and
devel/debug, where the first is optimized and the other is for
development. If you did this, freeglut programs would run faster and the
problem with the incompatibility with FLTK would go away.
Best regards,
Henrik

On 10/12/07, Stefan Roettger <Stefan.Roettger@...> wrote:
> Hi,
>
> I migrated from the old glut to freeglut.
> It seems to work all fine except that one of my freeglut demos
> fails to allocate an alpha channel if I request not only GL_RGB but
> also GL_ALPHA.
Please if this problem is similar to the one I faced here:
<http://tinyurl.com/28hwou&gt;
If yes, the fix is given here:
<http://tinyurl.com/237ufo&gt;
HTH,
~ash

Hi,
I migrated from the old glut to freeglut.
It seems to work all fine except that one of my freeglut demos =20
fails to allocate an alpha channel if I request not only GL_RGB but =20
also GL_ALPHA.
I traced the problem to freeglut, because I tried the same demo =20
with the old glut once again and it worked fine.
Any clue what might be wrong?
I am using Windows XP and the latest freeglut 2.4.
Thanks,
Stefan
PS: You can download the mentioned demo from my site: =20
http://www.stereofx.org/download/Yukon.zip. When displayed correctly, the =20
demo should show some ground fog and pseudo-clouds (which require =20
an alpha channel to accumulate the attenuation factors), but due to =20
the missing alpha channel they just don't show up.