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.

Using YUI components in a templated environment

If you develop sites anything like I do, you’ll end up setting up a site wide layout and theme before you start coding any individual pages. I like to add YUI components where they are useful, but I’ve come across a couple little quirks that were annoying me. Here are my observations and what I did to get around them.

Templating Quirks with YUI

The root of my annoyance is that I don’t need all the components I want to use on all my pages. I do however need some components on more than one page as well as sometimes needing a few components on one page. Somewhere along the line, I gained a believe that doing things more than once was not good. Copying and pasting header files and setup code between pages is on my list of less desirable behavior. This led me down the path of adding all the YUI header files to my master template for my site.

Advantage: All my pages have the header files already and I don’t need to worry about that on each page I’m working on.
Disadvantage: Pages with no need for a YUI component still use up bandwidth/time downloading the headers.

If you weight the disadvantages of putting the header files on every page higher than the advantages like I did, you might go the opposite route and try adding them only to the pages where you need the components.

Advantage: Only pages with the components are now loading the dependencies.
Disadvantage: You’re back to redoing setup work and/or copying and pasting a lot.

Dynamically Loading YUI Components

Well, I wasn’t entirely happy with either solution so I came up with a hybrid. I’ve watched the YUI-Loader with some interest since it was introduced a couple versions ago. It is now no longer marked as “Beta” and I figured it was worth looking at for my current project. The basics are this:

  1. Include the loader script.
  2. Create a loader with a list of objects you’ll be using.
  3. Use the loader to grab all the required resources.
  4. Use the resources you need.

Sounds like a good idea to me but I didn’t want to copy/paste loader initialization code in my template pages any more than I wanted to copy/paste header files. My solution is to create a generic loader in my master template and then override the required resources at the page level.

Here is part of my master template

<script type="text/javascript" src=""></script>
<script src=""></script>
<script type="text/javascript">
var yuiLoaderRequires=[];
var myOnLoad=function() {}
function init() {
var yuiLoader = new YAHOO.util.YUILoader({
require: yuiLoaderRequires,
onSuccess: myOnLoad
<!-- Using your template language, insert the child template javascript here -->
<script type="text/javascript">

Then, just override yuiLoaderRequires and myOnLoad in the subpages:

<script type="text/javascript">
myOnLoad=function() { doSomething....; }

I find that a lot less annoying than looking up requirements for each component on each page. Also, running the loader in the onDOMReady function causes the requirements to be loaded after the HTML has been rendered, this ought to give the appearance of a faster page load for most users. It might not work for every case though, so use with care. Hope you enjoy.

Image Upload with YUI Editor 2.5.0

The YUI team has been making further enhancements to the YUI library. I decided to stick together in one post all the previous resources I’ve added for the YUI Image Uploader and make sure the uploader was compatible with the latest version of the YUI Rich Text Editor.

Continue reading “Image Upload with YUI Editor 2.5.0”

Ten Principles Of Effective Web Design

Here is another article from highlighting some effective web design techniques. I’m stockpiling these for the next time I have a new project that requires a new face. This one is particularly informative since it gives examples at the beginning of how users use the web and then shows how you can take advantage of that. From the article:

Since the visitor of the page is the only person who clicks the mouse and therefore decides everything, user-centric design has established as a standard approach for successful and profit-oriented web design. In order to use the principles properly we first need to understand how users interact with web-sites, and how they think.

read more | digg story

Creating Image Preview Tooltips with the YUI Overlay Widget

The Yahoo UI Library provides a nifty helper for creating tooltips. I started playing around with it when I wanted to add the same tooltip to a large number of elements on a page. What got me interested in this implementation, is the ability to use the same tooltip on a number of elements, rather than having each element have it’s own tooltip div, or implementation.

The tooltip library creates a div element for each tooltip when the document loads. I wanted to use the tooltip to display a larger version of an image when a user hovered their mouse over a thumbnail. I did not however want to load all the full sized images when the page loads.

I decided the best way to handle this task was to implement my own tooltip function and create my own panel. Continue reading “Creating Image Preview Tooltips with the YUI Overlay Widget”

Upgrading to Xorg-X11 7.3 with ati-drivers 8.42.3 on Gentoo

I’m a sucker for bleeding edge technology. After posting before about upgrading to the 8.42.3 ati drivers, I realized I was using Xorg-X11 7.2, not 7.3, which is the latest. The latest 7.3 ebuild contains a block on the ati drivers. The block is no longer necessary though because the 8.42.3 drivers are compatible and have xorg-server 1.4 support built in.

Here is what I did to upgrade. Continue reading “Upgrading to Xorg-X11 7.3 with ati-drivers 8.42.3 on Gentoo”