Re: [Gtk-osx-users] problems building klavaro

[John Ralls <jralls ceridwen us>]

On Aug 31, 2010, at 10:28 AM, Benjamin Renaud wrote:

> 
> 
>> 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.)
> 
>> Sorry, IMs are one of the areas which Gtk+ hasn't implemented on OSX. See https://bugzilla.gnome.org/show_bug.cgi?id=617583.
>> 
> 
> 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?

Ah, sorry, I misunderstood. I thought that you meant that you'd gotten it to run successfully once on each system. What is the output when it crashes? Have you tried a debug build and gdb?

Xim is the X11 input method, and obviously the best solution would be the Mac analog, where Gdk just accepts the input text from OSX. Unfortunately the Gdk key handling is a bit low-level for that, so there isn't an easy solution. 

No, you bundle everything up and then point DYLD_LIBRARY_PATH at the bundle with a shell script (called a launcher script). Look at the examples in ige-mac-bundler. 

Regards,
John Ralls


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Gtk-osx-users mailing list
Gtk-osx-users lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtk-osx-users