On Thu, Jun 23, 2011 at 11:57 AM, Chris Smith wrote:

On Thu, 2011-06-23 at 11:50 -0700, Jason Dagit wrote:

...

What is your deadline for making sure you have a working library?

I don't know... August?  In any case, I do now have a working library, so long as I remember not to use GHCi for it!

While GLFW would certainly be far preferable to GLUT in the long run, the fact is that Gloss is already implemented using GLUT, and I can make GLUT work.  So I'll plan on using that unless someone else volunteers to port Gloss to GLFW.

(To be honest, I did consider it when I first ran into this problem a week ago; but after a few hours of hacking at it, it became clear that it's too large a job, and I'm far too unfamiliar with GLUT, GLFW, or OpenGL, for that to be feasible as yet another side project for me.)

Yes, I've suggested to the author of Gloss that he should switch to GLFW-b but he basically said what you said. He considered it when I mentioned it, but since Gloss already works with GLUT he wouldn't do it unless someone sent him the patches. Which is fair from a maintenance point of view. The downside is that all the windows users of Gloss have to get/install the glut32.dll from somewhere before Gloss will work for them. GLFW-b doesn't have that restriction. Also, when I first looked at GLFW I thought it didn't call atexit() (GLUT uses atexit(), which I think is kind of an evil C function, without having a specific gripe other than it being global mutable state), but it does actually use it. This line of thought always leads me to think that we should have a purely Haskell implementation of GLFW/GLUT on top of the platform specific gui bindings. At any rate, I'm glad to hear you have what you need for your class. Jason