Hi Conal,

For the record I have gotten gtkglext working with the native quartz backend, but it's not an entirely smooth process.  At least on Mac, several of the more serious problems have to do with the underlying libs (gtk+ and gtkglext), so I'm not sure there's much anyone on this list can do to improve matters.  I suppose I should submit my changes to the gtkglext sources upstream at least, but I didn't find a maintainer until today.

More below the fold...
From: Axel Simon <Axel.Simon@in.tum.de>

Hi Conal,

On 17.01.2011, at 01:06, Conal Elliott wrote:

> Several months ago I abandoned work on high-level programming for
> GIUs and interactive 3D graphics in Haskell, as I couldn't find any
> library that works natively on Mac OS X and doesn't kill ghci (or
> any host process) when a second top-level window is opened. The GTK-
> via-X11 route ugly and awkward enough to spoil the fun, and the
> native-gtk route didn't support gtkglext (for OpenGL).
> I read some very encouraging news recently on this list about
> gtkglext via Quartz, so maybe we're getting close to gtk2hs on Mac
> natively. On the other hand, the build process was complex enough to
> dissuade most potential users, IIRC.
> Is anyone actively working on an easy-to-build gtk2hs that supports
> gtkglext and runs natively on the Mac as well as Linux & Windows?
> Any realistic predictions about the effort?

We had a patch but probably need to put a little work in to make our
cabal package build with either X11 or Quartz backend. It will
probably boil down to setting a flag at the cabal command line. In
either case, the user has to install the binary libraries for the
cabal package to install.

The most recent gtk2hs patch addressing this requires a cabal flag, and I don't see that it's possible to do any better (i.e. I don't know how this could be auto-detected).

I think the Quartz backend of Gtk+ hasn't seen much love and that
stuff like the DND and the clipboard aren't really supported. But I
might be wrong about that.

 I agree that the Quartz backend needs more work; it looks like a shortage of developer time is the big problem here.  The sources are a bit unstable, and gtkglext needed a bit of hacking as well due to obsolete macros.

What can be helped is the gtkglext package.  There are bindings to functions that AFAICT don't exist in gtkglext. Specifically:


Can anyone confirm that definitions of these actually exist anywhere in the C source/lib?  If not, I propose they be removed from gtkglext.


PS - if you want to try installing gtkglext on Mac, I have a walkthrough of what I did (and patches).  Be warned: it hardly exemplifies good practice.