On Wed, Jan 26, 2011 at 7:25 AM, Axel Simon <Axel.Simon@in.tum.de> wrote:
Hi John,

On 25.01.2011, at 17:55, John Lato wrote:
 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. 

I'm sure somebody put those definitions in because they existed at some point. We should definitely #ifdef them out, depending on the version we're compiling. 


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.

You could write up an INSTALL file that we can ship with the cabal package. I can then put a link on our webpage (once it is up again) directly to that file so that the webpage is always up-to-date.

I think there are a few things that should be improved before this happens.  With the patch for using Quartz I think gtk is fine, and  gtkglext can be cleaned up as you suggest.  However I also had to patch the gtkglext C source (after I downloaded the quartz-hacked version), because it uses some no-longer-available functions.  It looks like the necessary changes are in the gtkglext-HEAD, but haven't tried it yet.

I'll give it a try, and if it works I'll write up an INSTALL file.