On Tue, Nov 10, 2009 at 1:10 PM, John Ralls <jra...@ceridwen.us> wrote:
> On Nov 10, 2009, at 4:16 AM, Paul Davis wrote:
>> On Mon, Nov 9, 2009 at 1:10 PM, Jack Skellington <dac...@gmail.com> wrote:

   I just wanted to take this ridiculously appropriate opportunity to
you on the great improvements on the OSX build I've seen this year.

I by chance had a contract that involved building a GTK+/GStreamer application
that primarily had to run on OSX; two very notable results:

   a.) I started doing osx builds of Glade, and even did the
ige-mac-integration thing,
        just because it was so damn easy to do, that says alot because
I've really had
        next to no time this year for hacking Glade.

   b.) I started to appreciate jhbuild for the first time, actually
now I just stay
        on osx and do anything GTK+ related on osx, just because damn it builds
        so easy on osx, easier than on ubuntu (hell I even built nbtk on my
        MacBook last week just for the hell of it, I only had to hack
the clipboard code
        and run an unstable clutter).

So thanks for making my job so easy, and thanks for making Glade and other
GNOME apps easily available on OS X ;-)


>>> Also if a native Gtk+ OS X framework were available people who are
>>> maintaining Gtk+ apps would have the option to extend their user base
>>> to OS X quite quickly.
>> All it requires to use it is to build the GTK stack yourself using the
>> instructions provided (i wish the instructions had not been moved away
>> from gnome.org, but they are still easy to find). I should put "all"
>> in quotes because if you choose to follow bleeding edge GTK then you
>> will find that maintaining your built version can be quite a lot of
>> work in the face of breakages and changes in many different parts of
>> the stack. This is not true (or at least, it is MUCH less true) if you
>> use a recent release version (there are instructions on how to do that
>> included in the gtk osx build info).
>> I do not believe that using a pre-built GTK OS X framework is
>> desirable for users or developers. Include GTK as part of your app
>> bundle. Its not hard to do and gives you complete control over which
>> version of GTK is used by your app. We do this for Ardour (and now
>> Mixbus) (screenshots at http://ardour.org/ and
>> http://mixbus.harrisonconsoles.com/). Users download a single app, and
>> run it. No framework installation or maintainance.
> I haven't built and made available updated frameworks because the approach
> Richard used to create the first one (still hanging around on gtk-osx.org,
> as previously noted elsewhere) didn't produce a result that I think I can
> support. I have in mind a modification of ige-mac-bundler which I think will
> provide better results, but other tasks have higher priority at the moment.
> Some others, including me, have done some work on the gtk-osx-frameworks,
> and the network graph at github shows that my tree
> (http://github.com/jralls/gtk-osx-framework) is current with all of them .
> Do be aware that there are 3 branches, of which master is probably the only
> one which will get you close enough to use.
> I also agree with Paul here: The Apple Framework idiom doesn't make sense
> for cross-platform development. It uses special #include syntax and special
> linking. It doesn't play well with pkg-config. Yes, those are solvable
> problems, but why? The regular gnu autotools work very well indeed on OSX,
> and one needs to use it anyway for building on Linux. Why deal with another
> build chain just for the dubious benefit of using XCode instead of emacs or
> vim?
> Add to that that it's hard to build a non-trivial application using only
> gtk+. You're going to need a bunch of other libraries, either from gnome,
> gnu, or freedesktop. They're not going to be in Frameworks, so you're going
> to have to integrate them the autotools way, so what do you gain from having
> gtk+ in a set of frameworks?
> There is one exception to which I'm quite sympathetic: PyGtk. At present
> building a downloadable PyGtk app bundle is a royal pain, and a PyGtk
> framework *might* be part of the solution.
> Regards,
> John Ralls
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-devel-list mailing list

Reply via email to