GTK+ programs with GtkBuilder and dynamic signal handlers.

Well, I decided to review some GTK+ and Gnome development lately. With GTK+, a nice way to create a user interface is with the Glade Interface Designer. Glade produces an xml file with a glade-interface element that can be loaded by libglade. You can then change attributes of the user interface without having to recompile your program. You just edit the design xml file and you’re good to go. Here are a couple things I noted during the process that weren’t too clear from the documentation:

  1. You have to work with C, not C++, if you want to dynamically load the signal handlers. Many times, it is convenient to write a program mostly in C, but use the C++ compiler and take advantage of a few of the niceties in C++. You can’t do that in this case. According to the libglade documentation, you’ll need to add -export-dynamic flag so that the dynamic loader for the signal handlers can locate the functions in the executable with the gmodule library. That doesn’t work with a C++ compiled executable. You’ll have to stick with C. If you really want to use GTK+ with C++, you can always try the glademm bindings instead of the default C bindings. You could also use gtkmm and write the entire program w/ C++ instead.

    UPDATE: I think you could get around this by using extern “C” around the function calls for the signal handlers. Then you could still use the automatic signal handlers while compiling with g++.

  2. As of GTK+ 2.0, libglade is deprecated. There is a new GtkBuilder interface that does the same thing. You no longer need to compile and link against the libglade libraries. I searched all over for a new interface designer to replace Glade but found a lot of references to people still using Glade. The xml file produced by glade is not exactly the same and not compatible with the GtkBuilder interface however. I finally found that there is a conversion function included with GTK+ 2.0 that converts the glade file to a GtkBuilder xml file.

    gtk-builder-convert <input file> <output file>

Anyway, with those two items taken care of, here is a really simple program and a really simple Makefile I put together to show how to get a GTK+ 2.0 program window showing.


void close_app(GtkWidget* widget,gpointer user_data) {
int main (int argc, char **argv) {
 GtkBuilder *gtkBuilder;
 GtkWidget *mainwin;
 /* Initialize the widget set */
 gtk_init (&argc, &argv);
 /* Create the main window */
 gtkBuilder= gtk_builder_new();
 gtk_builder_connect_signals ( gtkBuilder, NULL );
 mainwin= GTK_WIDGET(gtk_builder_get_object(gtkBuilder,"window1"));
 g_object_unref ( G_OBJECT(gtkBuilder) );
 /* Show the application window */
 gtk_widget_show_all ( mainwin );
 /* Enter the main event loop, and wait for user interaction */
 gtk_main ();
 /* The user lost interest */
 return 0;

LIBS=$(shell pkg-config --cflags --libs gtk+-2.0)
CFLAGS=-Wall -g -export-dynamic
hello: hello.c hello.ui
    gcc -o hello hello.c $(LIBS) $(CFLAGS)
    gtk-builder-convert hello.ui
For the sake of space, I’ll leave the xml contents out. Suffice it to say that there is a window, “window1”, and I set the destroy handler to “close_app”.

The Makefile converts to hello.ui, which is loaded by the hello program at runtime to produce the UI. You can of course build a window dynamically at runtime and you can also choose to connect the signal handlers manually. It just struck me as a lot less C code to do it like this.

Fixing Slow Resizing of Windows with Compiz and Emerald

One of the 1st things I noticed after upgrading to AIGLX with the new ATI drivers was that window resizing was incredibly slow. A quick search on Google yielded a LOT of results for the same problem. The first thing I noticed however, was that they were OLD forum threads. They did mention however, that when resizing a window, the window would be repainted to video memory each step of the way, and that the application would still repaint the window when you were done.

I decided to go look at the settings for the resize plugin with the Settings Manager instead. I found there are different modes for rendering the resize. My plugin was set to the “Normal” mode. I’m not sure if the normal mode has anything to do with the repeatedly re-render problem people had in the past, but I decided to try out some of the other modes. To my pleasant surprise, every other mode of resizing the window is quick and efficient. You can even choose the mode that visually suites you the best.

  • Rectangle
    Renders a rectangle that represents the new size of the window while resizing. The window is resized after you stop dragging. While resizing, the window is still visible in the background at the original size.
  • Outline
    Same as the rectangle mode but there is an outline instead of a filled rectangle.
  • Stretch
    This one is my personal favorite. The window is stretched to the size of the dragging rectangle and doesn’t actually repaint until you are finished dragging.

The perennially late Gentoo gnome-light ebuilds

If you run Gentoo Linux for your desktop, and you happen to favor the Gnome desktop environment, you may have noticed the incredible number of packages that need to be installed in order to install the gnome ebuild. The ability to pick and choose just those components you need for a system is one of the reasons I personally haven’t switched away from Gentoo to another Linux distribution. This ebuild however, seems to me to go somewhat against the original intent of the OS.

Continue reading “The perennially late Gentoo gnome-light ebuilds”