Skip to content

Which of these things look like all the others…

Well, gnome-settings-daemon has been tamed thanks to sound advice from Jonathan and Ed. It’s unfortunate that GtkSettings isn’t documented in any meaningful way, because it turns out it wasn’t a hard problem.

But, I wasn’t able to enjoy my success for long, because I now had to confront the other major obstacle in the way of thematic bliss: gtk-qt-engine. This notionally friendly little library is a GTK+ theme that uses QT for drawing, with the result that GTK+ apps look pretty much like QT ones. SuSE and, I think, Mandrake use it as part of their KDE desktops. However, there are a couple of problems that mar this seemingly sensible picture.

  • Firstly, SuSE uses a very unfriendly mechanism to include the theme: Rather than modifying ~/.gtkrc-2.0 and specifying the theme by name, they actually append the theme’s gtkrc to GTK2_RC_FILES in the user’s environment. This means that the theme’s rules are applied but not as a theme. As a result, it is not possible to ignore or override the theme! If we recall why gnome-settings-daemon was a problem (running on pre GTK+ 2.4 systems) we can quickly conclude that we’ve got a problem here too. Workstation 5.0 doesn’t address this because we wanted to helpful and not ignore the user’s GTK2_RC_FILES if at all possible, but I think that’s misplaced helpfulness, and it’s really going to be kinder to reset GTK2_RC_FILES to a sane value when we’re using our shipped GTK+ libs.
  • The second problem is a fundamental flaw in gtk-qt-engine itself: If you’re running a recent enough SuSE (or Mandrake?) distro, then your GTK+ is new enough, and we can actually use the gtk-qt-engine and everything looks great – except that the virtual device icons which are supposed to flash when the device is active don’t flash… Now, why don’t they flash? The code in question switches between the NORMAL and SELECTED bg colours to create this flash (It’s probably more correct to use the base SELECTED colour, but that’s a separate issue). This seems at first glance to be a reasonable mechanism because it’s a pretty pathological theme that doesn’t distinguish NORMAL and SELECTED. Well, guess what’s a pathological theme?

    It seems that either as a side-effect or an un-noticed bug, gtk-qt-engine sets all the gtk symbolic colours to the same value and relies on the fact that QT is drawing (almost) everything to produce something that looks correct. So, simply switching colours is never going to product the desired result. What’s a guy to do?

    One option is to calculate the activity colour on the fly, probably by inverting the NORMAL colour. That, at least, will provide some sort of feedback. However, what I’m currently inclined to go with is to override the expose handler and tell the EventBox to paint itself like the selected cell of a treeview. This should amount to the same thing as the old code in most cases and actually produces results with gtk-qt-engine. Now, that seems like a pretty crazy workaround to me, and it really shouldn’t be necessary, but when a pathological theme ends up as the default for major distributions, you don’t have a lot of choice.

{ 5 } Comments

  1. AdamW | 23rd August 2005 at 21:58 | Permalink

    We (Mandriva) don’t use gtk-qt-engine by default. We don’t even support it, it’s only packaged in contrib. Just an FYI :)

    (Our own theme, Galaxy, is implemented for kwin, qt, metacity and GTK+, drawn to match each other as closely as possible, and that’s what we use by default).

  2. Fer | 24th August 2005 at 00:40 | Permalink

    If you want your temable application to be SuSE-theme-aware you have to do:

    unsetenv (“GTK2_RC_FILES”);
    gtk_init (&argc, &argv);
    style_name = “your-theme-defaults”;
    gtk_rc_parse (YUOR_CUSTOM__OR_SYSTEM_GTKRC_DIR “/gtkrc”);

  3. Christian | 24th August 2005 at 04:17 | Permalink

    Another issues that might mar the picture is that a distro shipping this might only be allowed to ship GPL-compatible GTK+ applications as the whole GTK+ stack might need to stay compatible with Qt’s licensing when shipping GTK-Qt. Not a lawyer though, but it would be my assumption.

  4. Amadeo | 24th August 2005 at 07:22 | Permalink

    I am sure it is a bug in the gtk-qt-engine. Just contact the author, I am sure he will be happy with the feedback, and fix it:

    http://www.freedesktop.org/Software/gtk-qt

    The bug tracker is the freedesktop tracker. Here is th list of open bugs:

    https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=GTK-Qt+Engine&content=

  5. Philip Langdale | 24th August 2005 at 13:15 | Permalink

    Adam, thanks for the clarification. I suspected that was actually the case.

    I actually looked at the code just now and it is indeed as blatant as it seemed.

    NORMAL, SELECTED, ACTIVE and PRELIGHT are all mapped to the QT ‘active’ colour…

    Of course, QT only has ‘active’, ‘inactive’ and ‘disabled’ colours, so the way the other states are handled must be quite separate. Regardless, the current method is far from the right one.

    Amadeo, I’ll file a bug, but gtk-qt-engine seems almost unmaintained – there’s been no checkin for months.