libglade — C bindings for libglade


You can compile programs that use the libglade libraries with the command gcc program-files -o executable-name `pkg-config --cflags --libs libglade-2.0`.

Connecting signals

There are three different ways to connect signals to callback functions; the right way, the wrong way, and the very wrong way. Regardless of the connection method chosen, one needs to be aware that no type checking is done on callbacks. This means that return types, parameter types, and even the number of arguments in callback functions are not checked to see whether they are valid. This can be the source of errors if one is not careful.

Manual connection with the standard glib functions

The correct way to connect callbacks is to use g_signal_connect (and related though less frequently used functions such as g_signal_connect_after and g_signal_connect_swapped). Most importantly, these functions do not lead to bad programming practices, such as global variable use or polluting the global scope excessively with functions. They also provide the most control, do not require signals and handler names to be specified in the .glade file, and can be used together with the autoconnection method (one just needs to be aware that connecting a handler with the standard glib functions for which a handler is specified in the .glade file will result in multiple function calls per signal). This also has the added benefit that it is the same method as the one used by applications that do not employ libglade.

Libglade autoconnection

A wrong method to use to connect signals is libglade autoconnection. The reason that it is the wrong method to use is that it tends to make people structure their code in horrible ways. For example, because useful user_data cannot be passed to the signal handlers with autoconnection, people end up using global variables. Also, handler candidates for autoconnection need to be of global scope, which is suboptimal. For large programs, these two issues can cause headaches. Of course, these problems are not very important for small programs, so for such programs this method may make sense. Unfortunately, since all programs start out small, this has led to autoconnection being severely overused. The best choice of action to take is to simply neglect autoconnection. (Besides, if you are just going to write a small program, why not write it in a language such as Perl or Python? And let me just note that Perl and Python have modified autoconnection slightly so that it is not quite as problematic in those languages.)

The way that autoconnection works is that the handlers (function names) for each signal are specified in the .glade file, and then one calls glade_xml_signal_autoconnect within the program. As noted above, this method is somewhat restrictive. The only user_data that can be passed as a parameter to such callbacks is another widget within the .glade file (this is done by specifying an "object", which is the name of the other widget). However, this requires the order of the parameters in the callback to be switched and no other parameter or parameters can be passed to such a callback. Also, if one specifies a handler for a signal in the .glade file and then tries to use this method in combination with any other method of connecting callbacks, the callbacks will be called more than once per time the signal occurs.

While this method is not suggested, there are already existing codes that have used this method. So two examples are provided below to demonstrate how to use this method in case you run across such a code and need to work on it. Both examples are alternate implementations of the real gtk/libglade examples provided.

Libglade manual connection

The very wrong way to connect signals to callback functions is to use the glade_xml_signal_connect and glade_xml_signal_connect_data functions. I discuss these functions here only because you might run across other code that uses it (though thankfully that is somewhat unlikely since they are not used much). These methods are basically like the g_signal_connect_* functions (in fact, they are merely a thin wrapper over those functions), with the only real difference being that there are extra (potentially confusing) details to keep track of. They provide no advantage over the other methods in any situation. Using these functions means that one of these two functions must be called for each of the signals to be connected. These functions also require all the signals and corresponding handler names to be specified in the .glade file (which makes this method conflict with the autoconnection method, unless you do not mind callbacks being called multiple times). Like the autoconnection method, if an object is specified in the .glade file then the object is the first parameter to the callback.

While this method is not suggested, you may run across an existing code that have used this method. If so, you should really rewrite the relevant portions. To help you understand how to do so, an example of this method is provided, which is simply an alternate implementation of the second gtk example provided.