Re: [Gtk2hs-users] Gtk2hs-users Digest, Vol 56, Issue 2

[John L. <jw...@gm...>]

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 <Axe...@in...>
>
> 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:

glConfigGetScreen
glConfigGetDepth
glContextGetGLConfig
glContextGetShareList
glContextIsDirect
glContextGetRenderType

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

Cheers,
John

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.