Re: GTK on Macintosh OSX

[Dominic Lachowicz <domlachowicz gmail com>]

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.

On Sun, Jul 12, 2009 at 9:10 PM, John Ralls<jralls ceridwen us> wrote:
>
> On Jul 12, 2009, at 4:29 AM, Paul Davis wrote:
>
>> I have a fix for drag-n-drop that we have been using with Ardour for
>> more than a year. I will get into bugzilla for review. Its a pretty
>> simple patch. Not sure what problem you have with pasting, but that
>> works fine for all the purposes that we use it for in Ardour.
>>
>> We bundle Ardour for OS X and chose the "include GTK framework in the
>> .app". Ardour is fully relocatable - I believe I was responsible for
>> the description of how to do this that Richard wrote up. Its basically
>> a matter of using an apple-provided tool to both locate and reset the
>> paths to every library the app depends on. I have a nice little shell
>> script that recursively finds every dynamically linked object that the
>> app uses, copies it into the app structure and then resets the
>> link-time dependency so that its relative to the app bundle.
>>
>> Because we have/need a couple of hacks in GTK that are not likely to
>> go away anytime soon, I can't imagine us being interested in the
>> "blessed framework" approach.
>>
>> Regarding the general question of non-X11 backends being 2nd-class
>> citizens ... yes, I have seen and suffered from this problem when I
>> was doing work on gtk/osx last year and the previous year. It would be
>> nice if we could somehow get the core GTK team to commit to not making
>> changes that are not tested on non-X11 backends, but this seems
>> unlikely and the reasons are not totally unreasonable.
>>
>> Given that Ardour on OS X is critical to my income, you can expect me
>> to have a strong interest in keeping at least some version of GTK
>> functional on OS X and on continuing to fix issues that we encounter.
>>
>> --p
>
> Paul,
>
> Yes, the "nice little shell script" is part of ige-mac-bundler, a python
> program which populates a bundle and which is now in my care.
>
> But the problem isn't with rpaths. The problem is with path strings compiled
> into the library. Ardour must not run into this problem, but Gnucash does,
> in spades.
>
> There are three alternative solutions:
>
> 1. Build the library to use /Library/Application Support/Appname for its
> data prefix. Then the library can be bundled as usual, but has to use
> Installer to populate the data directory.
>
> 2. Bundle related libraries and executables into Frameworks with a
> hard-coded installation in /Library/Frameworks, and link the frameworks to
> the installation. Again, Installer is required.
>
> 3. Patch everything to discover if it's in a bundle, and if so use CFBundle
> functions to find its resources. This can create a drag-and-drop
> installation, but the work required is a bit daunting.
>
> There's one other, rather hacky, approach: Build into a $prefix, bundle with
> the install_name_tool routine turned off, and have the launch script create
> a softlink from the bundle's resources directory to $prefix if it's not
> already there. I've just implemented it for Gnucash. I don't think that it
> should be the "official" way, but it is a way.
>
> I'd like to see your fix for d-n-d. The problem I see with pasting is simply
> that when I cut something and try to paste it back in, nothing pastes. That
> could be a problem on the "cut" side instead of the "paste" side.
>
>
> Regards,
> John Ralls
>
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



-- 
"I like to pay taxes. With them, I buy civilization." --  Oliver Wendell Holmes