Hi Paul Paul Davis wrote: > 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. > 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
