Wubble

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.