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

[John Ralls <jralls ceridwen us>]

On Jan 18, 2011, at 12:59 AM, Anders F Björklund wrote:

> John Ralls wrote:
> 
>>> Getting some complaints that the bootstrap through jhbuild is
>>> too complex, so what I'm doing is installing just the /opt/gtk.
>>> 
> 
>>> Are you going to be hosting any pre-compiled jhbuild binaries
>>> on GTK-OSX's SourceForge ? I don't really want to bundle it...
> 
>> No.
>> 
>> Now I understand why you're whining about a separate bootstrap directory: You don't want to make a bundle. You're being silly, because the bundler pulls off only what the bundle needs from your build prefix and fixes up the rpaths. It's a much better solution than what you're trying to do. Better for your users, who get a nice clickable icon in Finder like they're used to, and better for you because instead of fighting the way the system wants to work you're letting it work for you.
> 
> That would have worked if it was just an application or two,
> instead of a bunch of small programs expecting to run PyGTK ?
> 
> It might still be done with the consolidation of those small
> programs into a larger "0install" binary (with matching GUI),
> but I don't see why you couldn't offer a binary installation.
> Even if it's just for developers to bundle libraries from...
> 
> Both the MacOSX/Quartz and Darwin/X11 versions _are_ working
> just fine, the only tedium was doing the initial bootstrap ?
> 
> But it's not ready for the casual Finder user just yet, and
> to be honest I'm not sure if GTK+ will be "enough" for them
> - or if it must be ported to Cocoa first (by using wxPython)
> Or perhaps even rewritten altogether, like the .NET version.
> 
>> The only catch is if your app needs dbus (usually because of GConf). In that case you have to make a link to the bundle's Resources folder from your build prefix. I've settled on using /Library/Appname, because /opt requires authentication even if the user is an Admin.
> 
> 
> It's not important that it was using /opt/gtk for convenience.
> It could have been made relocatable to another prefix, as well.
> 
> 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?). 

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.

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.

 

Regards,
John Ralls


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Gtk-osx-devs mailing list
Gtk-osx-devs lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtk-osx-devs