Re: GTK on Macintosh OSX

[John Ralls <jralls ceridwen us>]

On Jul 13, 2009, at 5:47 AM, Owen Taylor wrote:

> On Sun, 2009-07-12 at 19:47 -0700, John Ralls wrote:
> > On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
> >
> > > Glib on Win32 has routines to solve this problem. It resolves things
> > > relative to where the Glib DLL is installed. If your applications  
> > > use
> > > the XDG data directory functions in Glib, you might get away with  
> > > this
> > > too. Maybe you could invent something similar that used the OSX  
> > > bundle
> > > as your point of reference.
> >
> >
> > The routines only solve the problem if they're used.
> >
> > Don't need to invent anything. The core foundation functions are easy
> > to use, and Richard Hult already abstracted it into a gobject. But  
> > the
> > code still has to be patched. It's not just application code, either,
> > but infrastructure libraries like gconf, gnome-keyring, dbus, etc.
> >
> > I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find /
> > usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk'
> > \; ` and got more than 100 hits. Many of them are likely to be just a
> > define that isn't used for anything, but every one would have to be
> > examined, and a goodly number of them would require patching.
>
> Well, it's hard to say how many places Gnucash hard codes paths, but  
> the
> number of places in the GTK+ stack is nowhere close to 100.
>
> http://git.fishsoup.net/cgit/reinteract/tree/src/reinteract_wrapper_osx/main.m
>
> Sets only 7 environment variables before initializing GTK+ to get
> everything found properly within the bundle.
>
> I did need:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=554524
>
> Hmm, Behdad gave me the commit approval on that; didn't see that.
>
> Dom's suggestion of unifying with the Win32 functionality for locating
> paths relative to the executable makes a lot of abstract sense  
> though I
> haven't looked into the practical details of how it works out.
>
> - Owen

It is indeed hard to say. Gnucash includes binreloc code (an old copy  
and paste, not up to date) which I have patched to look in a bundle if  
one is available. This seems to have resolved the problem for the  
Gnucash part.

I know that GTK, Cairo, and Pango are not all of the problem; I even  
said so in my OP:
>  I realize that this is a bigger problem than just GTK, but it needs  
> to be addressed if GTK is to be a cross-platform framework  
> competitive with Qt and WxWidgets. Perhaps if there is a better  
> forum to discuss it someone here will point me at it.

The 100+ hits covered all of Gnucash's dependencies, and Gnucash is  
rather notorious for having a lot of dependencies. Most of them are  
likely to be harmless, but they all have to be checked.

Your solution in ticket 554524 is workable, if a bit inelegant. Have  
you committed it?

Regards,
John Ralls