Re: HOpenGL without GLUT

> Axel Simon wrote:
> > I thought about extending my gtk2hs with OpenGL functionality.
> 
> A good plan! :-)

more, more, more!-)

> > There is new functionality for Gtk version 2 which seems to just
> > add 3D rendering to normal widgets:
> 
> Just to be clear: Neither GtkGLArea nor GtkGLExt offer any kind of
> rendering capabilities, they offer the resource management for the
> current OpenGL context (i.e. the OpenGL state machine(s)).

Does that mean there'll be 3d-scenes running in Gtk menu entries,
dialogue boxes, buttons, etc.?-)

> The rendering itself is done always the same way, regardless of the
> Toolkit / resource management library in question (GTK, GLUT, WGL,
> AGL, GLX).

Yes, but the interfacing will differ. Most GUI libraries will
provide a superset of GLUT (otherwise, why bother?), so if you
really want to get into GUI-specific HOpenGL applications, there's
no way to avoid programming differences. 

It would be nice, though, to have a single basic API that would make
it easy to switch between a GLUT-based HOpenGL app and a Gtk-based
one. The de-facto standard is GLUT itself, so apart from providing
gtk2hs with access to GtkGLExt, a GtkGLExt/GtkGLArea-based GLUT
equivalent would be useful. Ideally, I just want to replace -package
GLUT with -package gtk2hs or something when compiling!-)

Cheers,
Claus

PS. Why do HOpenGL apps have to be that big (on win2k, the Klein
    example gives me a 4Mb executable, which seems to be standard 
    size for non-trivial, but tiny, examples; even the Planet 
    example gives about 1Mb, on win2k)? 

    Glut is already shared between HOpenGL apps, and small (easy
    to distribute to those who don't already have it); could other 
    parts of HOpenGL apps be shared out as well?

PPS. I know that Haskell programs don't tend to run on phones -
    does that mean that the embedded OpenGL iniatives are 
    irrelevant for HOpenGL?