After a few HOpenGL-free years caused by personal and job-related
circumstances, I'd like to work on this again. First of thanks to all
the people involved in keeping the binding alive, especially Jason!
Having the packages in the Haskell platform is simply great, because
it improves the visibility of the binding a lot and will keep new
users (and new bug reports ;-) coming.

I've browsed through the mailing list archives, so here are a few
miscellaneous remarks:

 *  The StateVar/Tensor/ObjectName packages are now in the OpenGL
package itself (in a different namespace), and the previous standalone
packages are still available, too. Although I don't think it is a
perfect solution, it was probably done to get the OpenGL packages into
the Haskell platform, right? If this was the motivation, I think the
price to pay was well worth it. The OpenAL/ALUT packages use the
assimilated packages, too, so I should probably update the former ones
to use the latter ones. This will introduce a dependency of
OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there
are very few programs using OpenAL without OpenGL, and the latter is
now universally available via the Haskell platformm, so this should be
the right way to proceed.

 * What was the exact motivation for using type synonyms instead of
the former renamings (newtypes) for the OpenGL types? Were there any
*real* problems or only potential/hypothetical ones? I am a bit torn
between those alternatives, so I'd like to learn the experience of
other people, including their opinions.

 * The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an
InvalidOperation in triangle's vertexAttribPointer calls, 'catch'
should probably be replaced by Control.Exception.{catch,IOException},
etc. Apart from fixing them, having GLUT versions of nehe-tuts in the
GLUT package would be great. I really like the idea of GLUT being a
one-stop-shop for tons of examples regarding the usage of the
OpenGL/OpenGLRaw packages.

 * Currently the binding doesn't work out-of-the box with ghci on
Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the
Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to
OpenGLRaw's library-dirs), but I'd like to solve this more cleanly.
More about this in a separate mail.

 * Finally Khronos has released the OpenGL registry in a less
braindead format
(http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-API-Registry-released?p=1251759),
so there is a good chance now that the OpenGLRaw package can be
completely autogenerated, something I wanted to do for ages. Judging
from the HOpenGL mailing list, Lars is already looking into it, so
let's coordinate our efforts here, preferably in a separate mail
thread. My main concerns here are: Include the generator (plus
pre-generated bindings) in the OpenGLRaw package, it really belongs
there. Don't put anything clever into OpenGLRaw, it should really,
really be a plain, straightforward 1:1 mapping of the registry. No
name mangling, structural modifications etc. apart from things
automatically derivable from the XML registry. A big question remains:
Can we generate the (un-)marshaling functions already in OpenGLRaw?
The XML registry has <groups>/<group> tags, but I fear that they are
still too incomplete/incorrect to be of any use for the Haskell
binding. On the positive side, I think that it should be possible to
upstream changes to the registry to make it more useful in general. I
had contact with Jon Leech in the past, and he has always been very
open and helpful.

 * Given the fact that OpenGL 4.3 is quite different from OpenGL in
the "old days", there are quite a few design decisions in the OpenGL
(convenience) package that I would do differently nowadays. But I
think with the feedback from the community we can gradually tweak this
layer to something more useful and up-to-date. Perhaps we can somehow
re-arrange things to be more in line with OpenGL versions/profiles,
but whatever we do, we should not drop support for "old skool" OpenGL,
there are *tons* of tutorials, books and courses relying on it, and
even NVIDIA has effectively promised to support this forever.

Cheers,
   S.

_______________________________________________
HOpenGL mailing list
HOpenGL@haskell.org
http://www.haskell.org/mailman/listinfo/hopengl