Re: [Gtk-osx-users] PyGTK on top of native GTK+?

[John Pye <john curioussymbols com>]

Hi John

John Ralls wrote:
>
> The wiki is at https://apps.sourceforge.net/trac/gtk-osx/wiki. You'll 
> need a sourceforge id to write to it.

OK, so I have run jhbuild, and I now have a working version of GIMP 
running on native GTK+. Couple of obvious bugs: command-Z for undo 
doesn't seem to work... something wrong with the keybindings, it seems. 
Also, the usual mouse-wheel zooming seems to be broken too.

What's next for getting PyGTK running? Do I have to tell jhbuild to do 
something, or do I download a separate tarball and build it manually?

>
> Yes, ige-mac-integration needs to be restructured a bit, and pulling 
> the python bindings out is one approach. I could also create another 
> module called ige-mac-pygtk which rebuilds it with python support 
> after building python, which makes it invisible to the user (at least 
> to the user who doesn't peer too deeply into the innards).

The key thing is that the dependency system of jhbuild works correctly. 
So I don't see why you would want to hide the module from the user.

>
> Fink and MacPorts are ugly hacks that attempt to recreate Linux inside 
> of OSX. They are rife with excessive and often conflicting package 
> interdependencies. I gave up on using either of them some years ago 
> after being unable to install Gnucash because of conflicting dependencies.

That would appear to be poor packaging practice, to me, rather than a 
fault of these package managers intrinsically, don't you think? 
Obviously there are some challenges to putting a package manager on top 
of an operating system that doesn't itself use one, but I think it can 
be managed. At least one should aim for a modular set of binaries that 
new developers can download in order to get started on a new machine.

>
> Gtk-OSX encourages a source build of the minimum installation for a 
> single app and bundling it for the exclusive use of that one app. Each 
> app contains its own dependencies, so there aren't any conflicts.

Yes, that's a different philosophy, I guess. User-centric, because you 
need to have a single download-and-install package for them, because 
that's what they expect on that platform. But I think that a package 
manager is the more elegant solution both for user and for developer.

>
> IIRC, to build MacPorts with Quartz you just pass an argument like 
> --enable-quartz to it at configure time.

OK. I'll look into it.

>
> It might be worthwhile for PyGtk to have a binary tarball. It wouldn't 
> be for non-trivial C apps, because there isn't any way for a single 
> package like that to satisfy all of the various other dependencies, so 
> it makes more sense to just build everything at once.

There has *got* to be a better solution than requiring every GTK-OSX 
developer to build their whole GTK+ environment from source. I thought 
that better solution was fink (apt-get) or Macports. But if it's not 
(certainly, I was surprised at how poorly maintained the binaries for 
fink are), then perhaps just a big whopper tarball of GTK+ for both 
Python and C users isn't so bad...?

Cheers
JP