Re: Status of GTK+ on Mac OS X?

[Paul Davis <paul linuxaudiosystems com>]

On Wed, Sep 2, 2009 at 2:11 AM, John Pye<john curioussymbols com> wrote:
> As I understand it, using jhbuild will allow me to conveniently switch
> between release tarballs and svn HEAD. It's also ensuring that
> dependencies are built in correct order, so I'm pretty happy to be using
> that for the moment.

that's one way to look at it, i suppose. i don't try to switch back
and forth. i just want svn.

> Having said that, I guess that tools like fink and macports replace the
> jhbuild dependency rules with their own dependency checking, so in that
> I guess you want to use the ./configure approach directly, right?

fink/macports are not really comparable to jhbuild in any way. they
are package management systems. jhbuild is a build system.

> I found that keyboard support in GIMP was broken. For example, in my
> jhbuild build of GTK and GIMP (John Ralls approach) I found that the
> command-Z undo keystroke didn't do anything. I guess there are going to
> be lots of bugs like this... but perhaps if I'm working from subversion
> head then there'll be less such?

there is nothing inherently broken about keyboard events in GTK with
the quartz backend. ardour has a rich set of bindings, and they all
work.

there is a general philosophical issue which i raised recently on
#gtk+, and that is the widespread use *within* GTK of specific
modifiers like control that breaks platform "nativity" - on the mac,
the cmd key is the primary modifier, not control. applications can,
with some work, fix this for their own bindings (we do this in ardour,
for example), but that doesn't address the default bindings of various
widgets. in addition, IMHO, GTK should encourage platform-nativity by
obscuring modifier masks like GDK_CONTROL_MASK and provide
GDK_PRIMARY_MODIFIER, GDK_SECONDARY_MODIFIER or something similar.

> Which is to say that none of the groups with hard development funding
> (GNOME foundation? Canonical? Apple?) have decided that GTK+ for Mac is
> a fundable priority, I guess.

That is correct. When Richard Hult was working on it, it was in part
because the company that he was working for believed it to be in their
interest (AFAIK). I am not sure why he stopped, but it could be that
it worked "good enough" for their purposes.

> Is there a buildbot somewhere running continuous integration testing of
> GTK+ with the Mac platform? What about other platforms? Is that
> something that the community is lacking in order to progress this stuff?

That would be a small contribution, and would at least alert the core
GTK development team to breakage caused by recent changes. However,
its not likely to result in any significant man power applied to
whatever issues exist.

> It would help a great deal if some of the old webpages
> on this topic could be cleared up.

which webpages?

> The issue is that there are no binaries.

you don't want binaries. really. you don't.

For Windows, a nice array of
> prebuild binary zips are hosted on gnome.org, but for Mac, there are no
> binaries, just an outdated Framework that doesn't work for me on OS X
> 10.5 (I couldn't find GTK+ in XCode anywhere).

bwahahahaha! GTK in XCode? forget it. Apple's XCode is a nice
environment if you're willing to weld yourself and your application to
their platform. The moment you want to start interacting with 3rd
party cross-platform tools, I consider it a fool's errand. Use a
decent cross-platform build system (we use waf these days), and forget
about XCode for cross-platform applications.

> case where the user already has a compatible version of GTK installed.
> Not without its challenges though.

not the least of which is how you determine whether they have a
compatible version installed.

> My app also involves a library of source files called our "model
> library"... we want those files to be user-viewable (even maybe
> user-editable), so I'm not sure I can do that with just a "bundle".

a bundle is nothing more than a directory tree with a specific layout
and a couple of specific files in place.

> The problem seems to me to be that loading a file from a bundle is not
> the same as loading a file from the filesystem. So I'm concerned that
> I'm going to have to cook up a whole lot of platform-specific
> file-loading stuff, both in my Python layer as well as in my C code layer.

i don't know what makes you believe this. there is nothing special
about a bundle *except* that Finder won't show you the contents
without extreme duress applied. there are some ways in which loading
files from within the bundle is *easier* than outside, because its
very, very easy to find out where they are.