Re: Status of GTK+ on Mac OS X?

[John Pye <john curioussymbols com>]

Hi Paul

Paul Davis wrote:
> 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.
>   

OK, I guess I'll get to that point too, if I find that a lot of bugs are
fixed there.

>> 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.
>   

There's more than a little bit of overlap between these two things,
because jhbuild knows about inter-package dependencies, and knows where
to download sourcecode from.

The extra thing that fink/macports do is maintain a system that allows
stuff to be uninstalled, and that knows what is on there.

>> 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.
>   

That sounds like a very sane approach, although at the cost of making
things a little more opaque for everyone.

Pleased to hear that the keyboard problem is specific to
GTK-OSX+jhbuild+GIMP.

>> 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 allow Mac users to be more informed about the problems as they
arise. I think that this would allow limited resources to be better
used: nipping problems in the bud.

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

http://www.gtk-osx.org/ ... "sponsored by imendio" (no longer true?)
 ... link at bottom of page to
"http://developer.imendio.com/projects/gtk-macosx/";

clicking the above "Developer page" link takes you to

http://developer.imendio.com/projects/gtk-macosx/
 ... contains "This page has been moved to
"http://live.gnome.org/GTK%2B/OSX";.

Clicking the above link takes you to

http://live.gnome.org/GTK%2B/OSX
 ... contains the text "Buiding, Bundling, and Integrating GTK on MacOSX
is now consolidated at http://gtk-osx.sourceforge.net";
 ... contains a list of problems, but it's not clear if this is being
actively maintained, because the  'main site' is elsewhere.
 ... is a wiki, but GTK-OSX has another wiki at
http://sourceforge.net/apps/trac/gtk-osx/wiki

IMHO it's in the interest of the GTK community for this stuff to be
cleared up and preferably hosted on 'official' GNOME- or GTK-branded
pages.****

>> The issue is that there are no binaries.
>>     
>
> you don't want binaries. really. you don't.
>   

Really, I do! I want to be able to get other developers on my project up
and running quickly and easily, on a well-known and reproducible
baseline system. I want a set of binaries with a functioning
'pkg-config' script that I can run in my configuration tests, to confirm
that they are using a valid version of GTK.

Most developers on my project are not GUI-heads... they're technical
programmers who generally complain if they have to build any
dependencies at all.

> 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.
>   

Well, there's been a significant effort from John Ralls to build a
Framework for GTK, which if I understand it correctly means that the
intent is that GTK could be used from within XCode.

I'm personally not interested in using XCode unless I can use it to
silently run my own SCons-based build (which it appears to have great
trouble doing).

BUT if this framework contains all the usual GTK binary stuff including
pkg-config, then I should be able to reuse it direct from the
commandline, right?

>> 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.
>   

That's easy, with something like pkg-config. If you know a certain
version works, you whitelist it.

>> 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.
>   
 
OK I'm learning a bit more about this now. Looks like a bundle (app,
framework, etc) is just a mirage created by Finder.

>> 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.
>   

Yes, looks right. Might not be so bad.

Cheers
JP