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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list