Skip to content

And not all 32s are equal…

Yep, still got time to kill, so I’ll tell a story. This is the story of what it takes to ship a gtk+ 2.4 based application that will run on RedHat Linux 7.2 out of the box.

If you think that’s a frightfully masochistic thing to want to do, you’d be right, but the old gtk+ 1.2 UI was looking pretty ratty and unimpressive when we released 4.5, so there was no question that 5.0 would be 2.x based.

Now, deciding that you’re going to require a newer version of gtk 2.x than is present on the system without requiring the system to be upgraded is a chore in and of itself, as you have to override a bunch of obscure envrionment variables, otherwise your private gtk libs will be busy trying to use the system’s old theme engines and pixbuf loaders to no good effect. But when you decide that you want to run on a pre-gtk2 distro like rh72, you’ve suddenly got a lot of dependencies you can’t rely on anymore.

It seems an awfully long time ago but back in those days, there was no fontconfig, Xrender or Xft; it was good old X server-side fonts and you felt grateful if you could use a truetype font at all :-)

I’m sure you can see the implications of this difference: we realised we’d have to ship all of those libraries along with the program, if gtk2 was going to work at all. And so began a labourious process of building all of our dependencies in a specially crafted virtual machine (of course) where things like glibc were the right version to ensure that the end result would work on rh72 and newer distros. And amazingly, it actually works. Nevertheless, I miss being able to just state what the requirements are and let the user worry about satisfying them. :-)

Ironically, the biggest inconvenience didn’t come from the pre-gtk2 distros but from the gtk2 < 2.4 distros. The problem is theme engine versioning: Our shipped copy of gtk 2.4 cannot use the 2.0 and 2.2 theme engines, so when the user specifies a theme that relies on one of these engines…

We attempted to mitigate the problem by providing our own gtkrc that always requests the default theme. But, this one wasn’t going to have a happy ending because of that wonderful tool: gnome-settings-daemon. gnome-settings-daemon has the characteristic of forcing a theme on all gtk apps and as far as we can tell, there’s no way for an app to override it and use another theme. The sad result, is that if your gnome destkop is using a theme with a theme engine, Workstation won’t be able to load that theme engine and things can get pretty ugly.

Things are, of course, better with newer distros where we can use the system gtk libraries and themes, but it’s going to be a long time before the minimum requirements for Workstation are a gtk 2.4 based distro!

So, the moral of the story is that you can actually ship a private gtk environment that depends on nothing more than glibc and X but you may legitimately wonder what the hell you’re getting yourself into if you try.

{ 5 } Comments

  1. Jonathan Blandford | 22nd August 2005 at 13:51 | Permalink

    You can actually override what XSettings tells GTK+ by doing something like:

    GtkSettings *settings = gtk_settings_get_default ();
    g_object_set (G_OBJECT (settings),
    “gtk-theme-name”, “theme-name”,
    NULL);

  2. Ed Catmur | 22nd August 2005 at 20:47 | Permalink

    Actually, it’s possible to override the gtk theme setting: use

    gtk_settings_set_string_property (
    gtk_settings_get_default (),
    “gtk-theme-name”,
    “HighContrastLargePrint”,
    “SporkNotUsed”);

    (or use gtk_settings_set_property_value, or even g_object_set); when properties are set on a GtkSettings it sets the source field on the relevant GtkSettingsPropertyValue to GTK_SETTINGS_SOURCE_APPLICATION, so then ignores what gnome-settings-daemon (well, via XSETTINGS) tells it.

  3. Mike Hearn | 23rd August 2005 at 02:52 | Permalink

    Why can’t GTK+ 2.4 load GTK+ 2.2 themes? Is it the GModule version checking stuff? If so that sounds like a bug in GTK+ to me, but I know we had problems with it when ClearLooks wanted to ship an autopackage.

  4. Philip Langdale | 23rd August 2005 at 07:55 | Permalink

    Mike,

    That’s my understanding of the problem. You’ll note that gtk+ 2.6 (and I hope, 2.8) still version modules as 2.4 – presumably for this very reason. Of course, it’s possible that there actually was some incompatible change between 2.2 and 2.4 but I rather doubt it.

  5. Philip Langdale | 23rd August 2005 at 17:27 | Permalink

    Jonathan, Ed,

    Works great. Now I get to complain about gtk-qt-engine…