This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jules Gosnell <Julian.Gosnell@nomura.co.uk> writes: > I am looking at guile-gtk-19980504 with an eye to adding a couple of new > widgets to it. Yes, that's probably the most visible new feature of guile-gtk, that you now should be able to use it for third-party widgets. I have never really tested it, tho, except for gnome-guile. So I'm happy that you are trying this out! You could simply hack your new definitions into gtk.def, add your widget libraries to the link stage of guile-gtk and be done with it. Of course, this is suboptimal, and rightly, you want to actually make new widgets available to Guile, *without* changing guile-gtk or even recompiling it. It should be fairly easy to do this, but you are the first to try it, so there might be some rough edges. > I would like to package my widgets and the guile-mywidget glue file into > a library that can be dynamically loaded into a guile interpreter on > demand and used just like the gtk widgets (but in a different package). This is the ideal thing. > I managed to persuade Guile to compile with dynamic loading supported. Congrats! ;-) I think there are some problems with the Guile configure checks for dynamc-linking, right now. > I had to relink libguilegtk.so with -R<some path> -lgtk -lgdk -lglib > -R<another path> -lXext -lX11, so that when it is dynamically loaded > into guile the symbols it references may be resolved. This is a well known libtool problem, or to put it into more fair words, a problem of several losing shared library implementations that libtool does not currently know how to address in a winning way. The next guile-gtk snapshot will include a slightly patched libtool that should reenable inter-library dependencies at least for GNU ld ELF systems. This is not a real fix and might actually give problems with static libraries, tho. > I have managed to compile my widgets into a new library, but was put off > when I tried to figure out how guile-gtk is configured to do : > > ./build-guile-gtk.in glue gtk.defs >tmpt && mv tmpt gtk-glue.c > > Am I following the correct path ? Yes, absolutely. You need to do the following to make guile-gtk glue code for your widgets. Let's assume you want to wrap the new GtkFoo widget, and its accompanying function gtk_foo_new. The following has not been tested! - compile and install guile-gtk - write your foo.defs file: ;; this imports the basic Gtk types, like GtkWidget (import "gtk.defs") (define-object GtkFoo (GtkWidget)) (define-func gtk_foo_new GtkFoo ()) - write your foo.defs.guile file: (options ;; all includes that the glue code needs (includes "#include <gtk/gtk.h>" "#include "gtkfoo.h") ;; the name of your init function (init-func "sgtk_init_foo_defs") ;; the name of the x-file with the snarfed initialization actions (snarf-file "foo-glue.x")) - generate the glue code from it with the installed build-guile-gtk % build-guile-gtk glue foo.defs >foo-glue.c - snarf it % guile-snarf foo-glue.c >foo-glue.x - write a module initialization function in guile-foo.c or something void scm_init_toolkits_gtkfoo_module () { scm_register_module_xxx ("toolkits gtkfoo", sgtk_init_foo_defs); } [This should actually be done by build-guile-gtk, don't you think?] - compile and link the glue code into a shared library % gcc -shared -o libguilefoo.so -fPIC foo-glue.c guile-foo.c -lguilegtk \ -lyourfoolib -lgtk -lX11 ... - install that library % cp libguilefoo.so /usr/local/lib - make a magic symlink % cd /usr/local/share/guile/toolkits % ln -s /usr/local/lib/libguilefoo.so libgtkfoo.so - Run Guile & guile guile> (use-modules (toolkits gtkfoo)) guile> gtk-foo-new #<primitive-procedure gtk-foo-new> That's the theory, at least. Please tell me how it goes. Marius