Re: GTK on Macintosh OSX

["Brian J. Tarricone" <bjt23 cornell edu>]

On 2009/07/11 11:14, John Ralls wrote:

> I'm concerned, though, about how committed the gtk development team is
> to completing and maintaining the internal parts. There are some serious
> holes (pasting and drag-and-drop don't work, just as a particularly
> egregious example). Richard told me that he hoped that some of his
> former Immendio colleagues would step up, but I don't see that that's
> happening.

I get the feeling that the quartz backend will probably end up like the 
win32 and (even worse) directfb backends: they'll require a few 
committed people to maintain them.[1]  As unfortunate as it is, I think 
it's just fact that the non-x11 backends are second-class citizens, with 
only the win32 backend receiving support anywhere near the level of the 
x11 backend.

What *would* be nice is if changes to the core of gdk get applied to all 
backends by the person making the change, similar to how Linux kernel 
developers are responsible for fixing up all API usage in drivers when 
they change an internal subsystem API.  But of course that's not 
feasible sometimes due to time constraints, and the non-x11 backends may 
not be deemed "important enough" to warrant that kind of attention.

Personally, I'm interested in the quartz backend, since I run MacOS X a 
not-small part of the time.  I've done some work on it, though it's been 
very minimal... I think I've submitted a grand total of two 
mostly-trivial patches (one of them to cairo's quartz backend).  I'd be 
interested in helping out more, but I can't promise any kind of time 
commitment.

> Beyond that, there is a deeper problem: Mac users expect their
> applications to be easily relocatable (the preferred method for
> installing software is a self-contained application bundle which can be
> dragged to and launched from any folder); many, perhaps even most, of
> the libraries in the GTK/Gnome universe use hard-coded paths which are
> established at build time.

Well, as for gtk, there are probably two main options:

1.  App authors bundle a gtk framework inside their app bundle.

2.  We have a "blessed" framework bundle containing gtk and dependencies 
that gets installed to /Library/Frameworks, and apps depend on that.

For #2, having relocatable gtk isn't that important, of course.  While 
Mac users are indeed used to being able to relocate applications, 
there's certainly a precedent for installer .pkgs that restrict the user 
to installing to a particular place.  Since it's not an application and 
gtk's existence should be mostly transparent to the user, I don't see 
that as being a big deal.

Either way, the win32 backend (which supports both #1 and #2) has 
facilities for locating where in the filesystem the gtk library is 
located at the present time, and this is used internally to allow the 
user to install gtk-win32 to wherever they please, and allows app 
authors to bundle their apps with gtk, which could also be installed 
anywhere.  I'd suggest looking into the win32 functions for doing this, 
and create OS X versions.

> I realize that this is a bigger problem than just GTK

Right... many (most?) apps aren't relocatable themselves since they 
refer to resources that may be spread all over the hard drive. 
Unfortunately this will require sending patches upstream per 
application, or patching the apps yourself (for various definitions of 
'your'self) before creating a distributable package.

As to a possible convention to adopt, I'd suggest keeping the 'normal' 
layout of packages as on a Linux system, but set the prefix so that it 
looks in the app bundle's Resources directory.  You can either use a 
wrapper script to set env vars and then start the app, or have the app 
figure things out in gtk_init(), perhaps (things like $(localedir) will 
need to be figured out so translations will work, for example).

I recall that the metapackage project had done some work on making 
relocatable packages... I'm not sure if that works on MacOS X though.

> Perhaps if there is a  better forum to discuss it someone here will
> point me at it.

Not sure if there is... not sure we need yet another mailing list tho :-P

	-brian

[1] AFAIK, there's no full-time directfb maintainer; seems like people 
who need it to work randomly come by and do a lot of work on it, and 
then disappear.  I believe Tor is the only win32 contributor; at least 
he seems to work on it vastly more than anyone else I've ever seen.  (My 
apologies if I've forgotten anyone!)