>Libglade Programming Notes

Libglade Programming Notes

Table of Contents
Libglade Programming Basics
Libglade Modules
Internationalisation with Libglade
Extending Libglade
Embedding Libglade Interfaces

Libglade is an alternative to using Glade's code generation. Instead of generating code from the XML interface description, libglade loads and parses the description at runtime. It also provides functions that can be used to connect signal handlers to parts of the interface.

In this way, it allows you to separate your program code from the interface code. In fact, if you use the glade_xml_signal_autoconnect() function, the GUI code could be as simple as the test-libglade.c example that comes with libglade. Of course, you would also add your own signal handlers to the code. Note that the signals are connected the same way as if you had hand coded the interface. There is no extra overhead to user interfaces constructed by libglade (after the initial generating of course, and this is not much of an overhead) when compared to a hand crafted interface.


Libglade Programming Basics

Your basic libglade program will look something like this:

#include <gtk/gtk.h>
#include <glade/glade.h>

void some_signal_handler_func(GtkWidget *widget, gpointer user_data) {
  /* do something useful here */
}

int main(int argc, char *argv[]) {
    GladeXML *xml;

    gtk_init(&argc, &argv);

    /* load the interface */
    xml = glade_xml_new("filename.glade", NULL, NULL);

    /* connect the signals in the interface */
    glade_xml_signal_autoconnect(xml);

    /* start the event loop */
    gtk_main();

    return 0;
}

This will create the interface from the file filename.glade, then connect all the signals in the interface. The automatic signal connection is done by looking up function names in the global symbol table using gmodule. This means that the interface file can use standard GTK functions such as gtk_widget_show, or gtk_main_quit, or others in the interface and not have to write any code to connect the signals.

The some_signal_handler_func function is not referenced anywhere in the program explicitely, but if any signals are defined in the interface description that use "some_signal_handler_func" as the handler name, then this function will automatically be connected. Note that the function can not be static, since we require it to apear in the symbol table. Here is an example of the XML that would cause some_signal_handler_func to be connected:

<widget class="GtkWindow" id="MainWindow">
  <property name="visible">yes</property>
  <signal name="destroy" handler="some_signal_handler_func" />
  ...
</widget>

Note: If you wish to autoconnect handlers defined in the main executable (not a shared library), you will need to pass a linker flag to export the executable's symbols for dynamic linking. This flag is platform specific, but libtool can take care of this for you. Just add -export-dynamic argument to your link flags, and libtool will convert it to the correct format.

Many people did not see this problem on GNU/Linux with GTK+ 1.2, because the gtk-config script adds the correct flag on that platform. Such programs would sometimes break when run on alternative platforms.

To compile the program, we would use the following:

cc -o testprogram testprogram.c `pkg-config --cflags --libs libglade-2.0`

The pkg-config program is used to deduce the compiler and link flags necessary to compile various modules. If you are using automake or autoconf, you probably want to use the PKG_CHECK_MODULES macro. This can be used to check for the presence of a collection of a number of packages, and set some shell variables:

PKG_CHECK_MODULES(MYPROG, libglade-2.0 libgnomeui-2.0 >= 1.110.0)
AC_SUBST(MYPROG_CFLAGS)
AC_SUBST(MYPROG_LIBS)