static int
compare_foo (const Gtk::TreeModel::iterator& a, const Gtk::TreeModel::iterator& b)
{
    std::tr1::shared_ptr<Foo> l1, l2;
    l1 = a->get_value (COLUMN_FOO);
    l2 = b->get_value (COLUMN_FOO);

    if (!l1)
        return -1;

    if (!l2)
        return 1;

    return l1->get_id () - l2->get_id ();
}

Can you spot the error? Running it under valgrind indicated that I was reading data from *before* the start of the array that was being sorted. In fact, the following lines of code in g_qsort_with_data() were causing tmp_ptr to be decreased back past the start of the array:

        while ((*compare_func) ((void *) run_ptr, (void *) tmp_ptr, user_data) < 0)
          tmp_ptr -= size;

Hmm. Why is there no guard to prevent tmp_ptr from being decreased past the start? Then I noticed the following comment up a few lines:

    /* Find smallest element in first threshold and place it at the
       array's beginning.  This is the smallest array element,
       and the operation speeds up insertion sort's inner loop. */

So at this point, the code is assuming that the very first element of the array is the smallest, so compare_func should always return >= 0 when it reaches the start of the array. Aha! So the problem is my compare_func. It turns out I forgot to handle the single case of both values being NULL.

    l1 = a->get_value (COLUMN_FOO);
    l2 = b->get_value (COLUMN_FOO);
+
+   if (!l1 && !l2)
+       return 0;

    if (!l1)
        return -1;

So there’s not really a big lesson to be learned here, but if you ever hit strange segfaults deep inside glib’s qsort while sorting a treemodel, do yourself a favor and double-check that your sort function is sane first. Also, do yourself a favor and run it under valgrind as soon as you get a strange segfault. Knowing the exact point of the invalid read is infinitely more helpful than waiting until that invalid read causes a segfault.

There is a very simple browser example in the source tree as well:

Since then it seems like I’ve been sick most of the time. Instead of doing something useful, I’ve taken to fidding on a re-write of my Agave colorscheme designer, and I’ve made a decent amount of progress. It still lacks a lot of features of the original, but it benefits from my vastly better grasp of gtkmm and related technologies. I still don’t know if I’ll ever actually get around to releasing it. It’s currently serving as a way for me to relax and take breaks from my other projects. It’s become sort of a playground for me to try out new technologies, and I think I’ve succeeded in making it nearly impossible for normal users to build as it requires quite a few very new or unreleased libraries (goocanvasmm, giomm, glibmm-utils, etc).

Here’s a little screencast of what I’ve done so far:

I’ve set up a repository on github for anybody that’s interested in playing around with it.

Also, I’ll be taking over some glibmm maintainer duties from murray after the 2.16.0 release.

cairomm

I’ve been hacking on cairomm and gtkmm for quite a while now, but cairomm has up to now been in a development state. For the gtkmm 2.10 release, we needed to depend on cairomm, so it had to be declared stable. So that happened over the weekend with version 1.2.0, followed on quickly by a 1.2.1 release to fix a small Windows compilation issue.

gtkmm

There was a slightly nasty gtkmm bug that popped up just after Murray released version 2.10.0 and went on vacation, so I had to try to get a new release cut in time for the GNOME release cutoff today. I’ve been developing my own Agave application for a while, but this is really the first time I’ve had to release software that A) matters, and B) needs to get done on a tight schedule. All in all a little nerve-wracking, but exhilarating at the same time.

Summer of Code

It’s great to see a updates on lot of the great summer of code projects within GNOME. It seems like this year was a really great year for SoC projects within GNOME. Great job to all the participants.

Life

This weekend I actually got some excercise. Sunday Joanne and I decided to go to the park across the street and play a little bit of tennis. I’ve never really played much tennis in my life, but I’ve decided that I really like it. I even went and bought some new tennis balls since the ones we had in the house were all old and flat and barely bounced. Maybe I’ve finally found the thing to get me off my ass and get some excercise every now and then.

Update: for those who don’t have any idea who I am, I wrote a little introductory post that didn’t seem to get picked up by planet GNOME when I posted it.

I’d really like it if the main website and the documentation (API and tutorial) all shared the same basic page structure and stylesheet, but there are a few complications. For instance, the main website source is located in the gnomemm-website cvs module, whereas the gtkmm API and turorial is located in the gtkmm module, and sharing files between cvs modules is difficult (impossible?). In addition, the main website source is static html, the API is generated by doxygen, and the tutorial is generated by docbook stylesheets. Getting all of these to generate the same general structure is probably possible, but again would require a shared html header and footer template between the two cvs modules.

So there are some issues that I’d really like to resolve, but I think it’s already a big improvement over the old site, so further improvements are on the backburner for now while I work on some actual code. If you have any comments or suggestions, feel free to send them to gtkmm-list.

I’ve also updated the information on the cairomm page significantly, which was previously very sparse. It could still use some more love, but at least it shouldn’t be much of a barrier to involvement in cairomm anymore.