A couple of emails and comments got lost at some point and I’m late-responding to them. Most are about projects I blogged about but have not worked on since.

Eoin Hennessy has taken over GstRaopSink development. He actually got it up and running, and set up a git repository with the code.

I was also requested to publish the source code of the Nurikabe generator. The co-author, Vladimir Panteleev, was okay with it, so I uploaded the source code of the generator and half-done GUI with a GPLv3 license.

I’d like to take a moment and briefly blog on a different subject.

My brother is getting up to speed performing as a DJ again, going by the stage name Eric Preston. If you’re into minimal techno, you’ll definitely want to tune in to his monthly livemixes at ericprestonmusic.com. The first of which is now available for free. I think you’ll be pleasantly surprised.

I spent last week messing around in Python with a concept I had in the back of my head, and a problem I bumped into was figuring out what widget was drawing what on the screen in GTK+. So yesterday I sat down and wrote a set of tools to do that.

First part is a GDB script that automates the process of breaking on a gtk_paint_* operation and dumping the necessary information. This was written with The Widget Factory in mind, so if your application needs parameters, or is written in Python, it needs adjustment. I’ve also uploaded some gzipped sample output of The Widget Factory.

Second part is a Python script that reads the redirected GDB output and visualizes it like so: (click the thumbnail for the full version)

It doesn’t draw images, text or polygons, but it shows most of the original. I found it helpful in figuring out what kind of calls widgets make when drawing, but also seeing from the theme engine point of view how the methods are invoked.

Translucency in GTK+ theme engines, as presented by a Murrine developer, is really nothing special. In fact, it’s overhyped. (Blog posts, news articles, etc.) It’s been around since day one when GDK implemented RGBA visual and Cairo support.

Here’s the Mist engine with a translucent background:

The big problem is, and Cimi’s blog post does mention this: it needs application support. The theme engine can easily detect and perform drawing with translucency, but it’s up to the application to actually enable it. One way to do this is using a snippit of code like this, after gtk_init and before any windows are created:

 GdkDisplay* display = gdk_display_get_default ();
 gint nscreens = gdk_display_get_n_screens (display);
 for (gint i = 0; i < nscreens; i++)
 {
     GdkScreen* screen = gdk_display_get_screen (display, i);
     GdkColormap* rgbamap = gdk_screen_get_rgba_colormap (screen);
     if (rgbamap != NULL)
         gdk_screen_set_default_colormap (screen, rgbamap);
 }

Another way to do this, is to patch GTK+ itself to prefer RGBA surfaces over the trusty old RGB surfaces. Trusty, because RGBA still tends to break some applications, and probably some GTK+ custom widgets as well.

So to get translucency, either all applications need to be patched, or GTK+ needs to break compatibility. Patching all applications is a rather stupid option, if we have to do that anyways once GTK+ breaks compatibility. I say it’s about time for GTK+ 3.0.

Though I think it’s overhyped, I guess that it will end up to be a good thing. Maybe we will finally get a push for more of this great bling in GTK+.

By the way, here’s the patch against gtk-engines trunk for the above screenshot of translucent Mist:
http://stephan.kochen.nl/proj/gtk-translucent-mist.patch

The last couple of weeks I’ve spent working with C#. I had already seen and worked with it before, during my study, but this time I worked on a personal project. I’ll make another post about the project itself in the future, but now I’d like to write about C# itself and the platform surrounding it.

I’m normally a bit skeptical of anything Microsoft produces, but I’ll say C# is a rather nice language in itself; a bit more so than Java. There’s nothing spectacular about it, but it does offer some things that would make me prefer it over Java. I’m thinking small things like events, readonly fields, and no silly restriction of one class per unit.

That’s just the language, though. I don’t feel like judging the standard libraries. But I can say that I’ve had no significant dissappointment there either.

What this post is really about, however, and what gets me quite excited, is MonoDevelop. I dare say that this is shaping up to be the integrated Rapid Application Development environment for GNOME. It’s a bit buggy, I still can’t find any debugger integration (but saw screenshots of work in progress months ago, so I guess it’s in the pipeline), but altogether I really wouldn’t be able to point out any other IDE quite like it. And this comes from someone who’s otherwise quite firmly in the Eclipse camp when it comes to Java, Python, C/C++ and D.

The builtin GUI builder Stetic works well, writing signal handling code is a snap, other features I expect from an IDE are there as well: refactoring, class browser, compiler error parsing, code completion, etc. Perhaps the only thing really missing is the debugger integration.

Even tough the project I’m working on has both a Windows Forms and GTK# front-end, development primarily takes place in MonoDevelop. Updating the Windows Forms front-end is often postponed until right before a release.

So that’s it. I just wanted to dedicate a post to this great emerging platform.