Le 31 août 2010 à 05:37, John Ralls a écrit : On Aug 30, 2010, at 3:02 PM, Benjamin Renaud wrote: Dear all,
I’m new to gtk-osx, but I must say that avoiding X11 has been a dream of mine since quite a while… So, sorry if my questions may sound ‘newbie’, but I really, really want to make this work!
I’m trying to build klavaro, which is a rather simple gtk-based “touch typing tutor”, and is supposed to require only gtk+2.0 (>= 2.16.0) and gtkdatabox (>= 0.9.1.1). So I’ve been installing gtk-osx, carefully following the instructions, everything went fine, so I assume it’s working (is there a way to check that it is?). Then, as I couldn’t find a .modules file for building gtkdatabox and/or klavaro, I wrote my own (copied below), configured the .jhbuild-custom, etc.
* gtkdatabox seems to build fine, but I don’t know how to test wether it’s actually working (so… I assume it is) ; * I had to modify slightly the Makefile of klavaro for making it work (there was an -export-dynamic flag somewhere for ld, obviously causing an error, so I just deleted it — tell me if I’m wrong), but then the build was said successful.
However, in fact I tried three times on three different partitions of my Mac (they’re all running Snow Leopard 10.6.4, by the way, and I believe XCode is up to date), and it only really worked the first time… but I can’t figure what exactly I did different on the three occasions! (The second and the third time, the application did build, but then it crashes more too often to consider it working. With the first build, it also crashes a lot, but the basic things seem to be working almost normally.)
So my first question would be: any idea why it worked only once? Is there a way to investigate what’s going wrong? Do I miss something in the .modules file?
Second question: on Ubuntu (for example), you sometimes have to put something like in your configuration file, in order to make GTK applications use the standard input method instead of GTK’s own. I seem to need that in order to make ‘dead-keys’ work normally (i.e when I type ^+E, I obviously want to have ‘ê’, not ‘^e’ — in french, we need diacritics a lot more than in english…). What would be the equivalent with gtk-osx?
Last question: I have tried to make a standalone bundle, but I suppose the .bundle file was incorrect, cause the bundled app wouldn’t work anywhere else than on the partition where it was built. How do I determine what I have to include in the bundle?
Thanks if anybody can help me a little…
Benjamin
<?xml version="1.0"?> <!DOCTYPE moduleset SYSTEM "moduleset.dtd"> <?xml-stylesheet type="text/xsl" href=""?> <moduleset> <include href=""http://github.com/jralls/gtk-osx-build/raw/master/modulesets-stable/gtk-osx.modules">http://github.com/jralls/gtk-osx-build/raw/master/modulesets-stable/gtk-osx.modules"/> <repository type="tarball" name="sourceforge" href=""http://downloads.sourceforge.net/sourceforge/">http://downloads.sourceforge.net/sourceforge/"/>
<autotools id="gtkdatabox" autogen-sh="configure"> <branch repo="sourceforge" module="gtkdatabox/gtkdatabox-0.9.1.1.tar.gz" version="0.9.1.1"/> <dependencies> <dep package="cairo"/> </dependencies> </autotools>
<autotools id="klavaro" autogen-sh="configure"> <branch repo="sourceforge" module="klavaro/klavaro-1.7.0.tar.bz2" version="1.7.0"/> <dependencies> <dep package="gtkdatabox"/> <dep package="libcurl"/> </dependencies> </autotools>
</moduleset>
Well, for a newbie, you certainly dove right in!
… let’s say I’ve been trying to do my best before asking for help! ;-)
well, anyway, thanks a lot for answering, and fast. The easiest way to test that your gtk+ build is OK is to run gtk-demo from a jhbuild shell. I've never heard of gtkdatabox; perhaps it has tests (make check is the usual incantation, and there's a way to do it from jhbuild, see their docs), a demo or an example that you can build and run to verify that it's running.
No, with the amount of information you've provided, there's no way to tell what's going on with klavaro. The usual reason for something to run once and fail forever after is that it has written a state file (which would canonically be ~/.klavaro or ~/.klavarorc, but who knows?) and that state is borked. If that's the case, just delete said file and try again.
No, I think it’s not likely to be the actual reason here: I’ve tried three different builds on three different bootable partitions of my hard-disk, so it’s almost like if it was on three different computers… The one succeeded built is running ok, I mean repeatedly ok (well, apart from some occasionally crashes!). If it's crashing, there's a CrashReporter file that you can look at with Console.app. It will at least tell you why it crashed and give you a stack trace. You'll probably have to debug it to really find out what's going wrong. Your best bet for help will be with whatever support (mailing list or forum most likely, IRC channel possibly) klavaro's devs provide.
Yes, I’ve already asked them, but no answer so far — I’m not sure they’re very interested on porting it to OS X… (Or maybe it’s just holiday for them.)
Hmm… That’s quite annoying, because it would mean that any GTK+ app requiring text would be almost unusable with any other language than english! Anyway, my question was precisely about knowing how to avoid GTK-specific input method, and go back to the “normal” input method. On Linux/Ubuntu, the command export GTK_IM_MODULE=xim is indeed about setting the input method of GTK to be the standard X.org input method.
Let’s hope someone will find a way to deal with that, or implement what it needs… You're not ready to make a bundle until you get it running from the command line. The bundler will automatically pick up dylib dependencies but can't see dlopened ones. If it crashes because it can't find something, the console log will say what, and you can add that to the bundle. You can also define DYLD_PRINT_APIS on the command line when you run the program (from the command line, of course) and you'll get a list of dlopen calls as they happen. The catch, of course, is how the path is encoded for finding the file. If it's hard-coded in the executable, then the only way to get it to load is with a symlink from the $PREFIX/lib back to the bundle's resource directory. OTOH, if it pays attention to DYLD_LIBRARY_PATH, then you can set that in the launcher script to point to the bundle. The launcher scripts that ship with ige-mac-bundler have examples of this.
ok — just to be sure that I get it right : if I do something like that, setting the DYLD_LIBRARY_PATH in the launcher script, then it’s not really stand-alone anymore, I can’t copy the bundle to someone else’s Mac, right?
best regards
benjamin |
