Re: [Gtk-osx-devs] GTK-OSX Binary Package

[Anders F Björklund <afb users sourceforge net>]

John Ralls wrote:

>> And I don't understand the hostility ("whining", "silly") here.
>> Just thought that it could be _useful_ to have a GTK+ stack for
>> Mac OS X, just like one is available for Windows from gtk.org ?
>> Even if real Mac OS X apps would bundle stuff inside the .app.
>> 
>> Like these quotes from http://www.gtk.org/download-windows.html:
>> 
>> "The packages here are for people who develop software that uses GTK+. This page is not intended directly for end-users. It is expected that people who build installers for GTK+ applications for Windows bundle GTK+ with them."
>> 
>> "If you find choosing, downloading and unpacking the individual zip archives below a chore, there are all-in-one bundles of the GTK+ stack including 3rd-party dependencies, both of GTK+ 2.16 and 2.22. The bundles contain both run-time and developer files. Many of the developer files are relatively irrelevant. If you intend to redistribute the GTK+ run-time, you need to figure out which files you can leave out yourself."
>> 
>> So I was using jhbuild to do something similar for Mac OS X...
> 
> "Whining" because you want me to change things around to suit your way of doing things when a one-line change to your .jhbuildrc-custom would take care of it. "Silly" because you seem to think that a Mac user will open Terminal to launch a gui application (which you say isn't even so much an application as a set of applets).  Oh, and do I understand correctly that you're building a universal binary for i386 and x86_64, but not PPC? That seems like a lot of extra effort for no gain at all unless you're doing something that needs the extra address space (GL, maybe?). 

Well, I could have done a build for PowerPC too but that would take up even more disk space. And the old "lipomerge" script I was using didn't support more than two architectures, which could be improved upon I suppose (or use another lipo script).

But, the reason to build two binaries is because Python requires the module architecture to match. So when running on Snow Leopard x86_64, it would need -arch x86_64. But on Snow Leopard i386 or Leopard (either, python2.5), it would need -arch i386.

Otherwise you get runtime errors from Python like:

ImportError: dlopen(foo.so): no suitable image found.  Did find:
	foo.so: mach-o, but wrong architecture

And the programs use some glib/gobject features even for the console, so I would need that either way. And the easiest way to get both CLI and GUI, is to install the whole PyGTK stack (with dependencies, like PyGObject).


It does create app bundles for installed launchers, but having to bundle GTK+ (and Python) with each sounded scary ?
So it's only a small shell wrapper, like so: http://afb.users.sourceforge.net/zero-install/launchers/SeaMonkey.zip
On other desktops (GNOME/KDE), it's: http://afb.users.sourceforge.net/zero-install/launchers/zeroinstall-seamonkey.desktop
For reference, the process for those other desktop environments is detailed at http://0install.net/tutorial-launchers.html


You won't need the Terminal for the other tools (see http://0install.net/tools.html) either, once they are ready...

But before that happens, it's "easier" to just install PyGTK into /opt/gtk and set up the PYTHONPATH to include it.


> If you are willing to do the building and supporting ("I downloaded your binary of Gtk and tried to build GIMP against it, but it won't build!!!! HELP!!!" will be typical), sign up for SF and I'll give you access to upload it to the Gtk-OSX area. Or you can offer on gtk-dev, maybe they'll host it. I have enough to do without taking that on.

Okay, that's fair enough. If my (fully automated) jhbuild packaging works out, I will do that. I have this feeling it's not *really* the building part of the install, even if that was the complaint given at the time...

> BTW, if you're committed to cross-platform and not yet committed to gtk, I do recommend that you select a different framework, one that compiles natively with MS's tools rather than requiring msys or cygwin. Wx is an good choice. It will get you closest to a native look-and-feel on each platform of the choices of which I'm aware. PyQt is also a good cross-platform choice which has the advantage of having a large paid programming team, though Qt apps tend to look like Qt apps rather than native ones. Tk is equally ugly everywhere. I've no experience with pyFLTK, but it looks interesting though a bit immature.

wxPython has the best options, since it is included with Mac OS X and uses LGPL rather than GPL. PyQt4 still uses GPL even if Qt4 is now LGPL, and that other binding didn't seem as complete yet. Agree on Tk/FLTK being ugly.

Windows was only mentioned as an example, even if MinGW works just fine when I'm building for Windows. And the project is fully committed to Python and GTK+, just wondering if it will ever be "enough" for Mac OS X users ?

Personally I'm fine with running GTK+ either through X11 or as unthemed Quartz, I want a working GUI rather than something "native". If that was what I wanted most, I wouldn't have used GTK+ ? (wxWidgets does use GTK+ on Linux)

--anders