Re: GTK on Macintosh OSX

[Owen Taylor <otaylor redhat com>]

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