Skip to content

GtkEventBox abuse…

Good news! I’ve now got a satisfactory alternative for controlling the background colour that makes gtk-qt-engine happy, along with a couple of other pathological themes.

The method we were previously using to set the background colour was to stick the widget(s) inside a GtkEventBox and then call modify_bg() on it to set the background colour. This seems to be an inocuous enough thing to do and controlling the background colour is one of the officially stated uses of the event box, but maybe I wasn’t supposed to do it that way; comments are welcome.

Unfortunately, this method was the one that gtk-qt-engine was refusing the cooperate with. In addition, themes like Crux and Smokey-Blue both have rules that override the appearance of event boxes to look like their parent widgets – in essence to make them transparent. Now that is surely a pathological behaviour. The vast majority of themes have no problems.

So, on to the final solution. I dug around inside the gtk-qt-engine source to try and find out what it was doing wrong, and while I couldn’t nail that one down, I did see how it was rendering certain elements without using QT directly. This implied that colour selection could not be completely broken. So working from yesterday’s proposal to paint the box as if it was a treeview cell, I ended up just using gdk_draw_rectangle to colour in the background; For whatever reason, gtk-qt-engine sets the gc’s correctly even if it doesn’t set the colour values right. At the same time, I changed our widget to stop inheriting from GtkEventBox and used GtkHBox instead as the simplest non-abstract container. Changing the inheritence hierarchy allowed Crux and Smokey-Blue to work because our widget would no longer get matched as an EventBox.

The story has a happy ending, but it’s unfortunate that valid techniques are rendered unusable because of theme-specific pathologies.

{ 1 } Trackback

  1. […] Wubble I’m sure I’ve got two pencils around here somwhere… « GtkEventBox abuse… […]