Re: GTK on Macintosh OSX

[John Ralls <jralls ceridwen us>]

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