On Wed, Sep 2, 2009 at 2:11 AM, John Pye<john@xxxxxxxxxxxxxxxxxx> 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. > 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. > 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. > 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 help a great deal if some of the old webpages > on this topic could be cleared up. which webpages? > The issue is that there are no binaries. you don't want binaries. really. you don't. 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. > 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. > 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. > 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. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
