It’s not a non-SDL discussion yet 
Glut doesn’t go fully-fullscreen on Linux either. Anyway, glut is simply the
wrong interface for me. Its widget set has a tiny fraction of the
functionality of FLTK’s and has only one mode of operation: embedded in the
OpenGL surface. FLTK looks capable of running either in the OpenGL surface
or outside, or both at the same time. (Note: I have not tried this yet, but
soon.)
It may be a small thing, but I don’t like having the widget set run my event
dispatch loop for me. My application is not widget-centric, it is rendering
and realtime response-centric, so I want to run the main loop myself thanks.
FLTK lets me do this, glut does not.
Running the dispatch loop myself instead of letting the widget set do it
makes a bunch of interface glue go away. I don’t have to register an idle
routine or any of the usual callbacks, I don’t have to have a separate
function for every different kind of gui event, I can centralize my logic for
deciding when the screen needs refreshing, etc. The bottom line is, keeping
the main loop in my own program makes it shorter and gives it more accurate
control at the same time, so this seems fundamentally right, and conversely,
the traditional callback way of doing it seems fundamentally silly.
Glut provides some basic text rendering capability inside the OpenGL surface,
which is the only feature of glut I use at present. Really, this should be a
separate library, with a lot more flexibility and higher rendering quality
Glut’s basic polyhedra drawing is something you either just want to code
inline in your application, or you want way more capability, such as
constructive solid geometry, scene graph, etc. Basic polyhedra are only
useful for demos, and simple ones at that.
Glut’s window management is pretty basic, so is SDL’s. But SDL caters better
to the need to support both blitting and OpenGL drawing to the same surface
and will handle color depth mismatches for you, so SDL does quite a bit to
cut down on interface hassles.
Glut has filled an important niche in the past in that it gives you a way to
run the same OpenGL program just about everywhere, gives you enough of a gui
to set some options, enough text to communicate with the user, and that’s
about it. Enough for then, but not enough for today, plus its interfaces are
more verbose than necessary. So, a big thankyou to Mark Kilgard for
supplying this important component and making it easy to get started writing
OpenGL apps, but for me it’s a thing of the past.
I tried a little experiment on this FLTK+SDL demo:
http://www.turricane.org/~wizard/projects/fltk-demo/
I added the SDL_FULLSCREEN flag where it creates the SDL window. The result
is interesting: the application goes to fullscreen, displays the SDL window
briefly, then wham, it’s back in windowed mode as the FLTK window opens. OK,
I was asking for something impossible and at least it did not crash. Now,
what do I have to do to get the FLTK window to open up inside the fullscreen
SDL+OpenGL surface when the app is fullscreen, and outside when its not? I
believe I can do it, but it’s going to require some work. This is the real
test of whether I have the right widget set.
Regards,
DanielOn Tuesday 28 January 2003 11:04, Gib Bogle wrote:
I just installed FLTK on W2000. I built and tested the OpenGL samples,
and they look OK. But I have run into what appears to be a limitation.
Adding glutFullScreen() to a demo program makes it almost, but not
quite, full screen. The Windows toolbar is left on the screen, as is
the Office bar on the right edge. I can’t see how to display the OpenGL
scene on a bare screen, which I need. If you know how to do this,
please let me know. (Should we take this non-SDL discussion off the
list?).