Well. The colors are set on deskbar/ui/cuemiac/Cuemiac.py lines 440 and 441. Namely by:

	self.header_bg = gtk_style.bg[gtk.STATE_NORMAL]
	self.match_bg = gtk_style.base [gtk.STATE_NORMAL]

So they do infact use the theme colors, but it is a more or less hacky way to apply them. If any one can find a better way to get good colors, feel free :-) I'm stomped...

Perhaps this could be marked as gnome-love.

Not it's too complicated in the GTK api for a beginner.

Why do you have to specify explicitely the background color in the normal case ?

Couldn't you just use the standard BG color when the renderer is instancied, and only switch to grey when you have a category ? (or better, use a themed grey, like the insensitive one) ?

I need those color values because I set the cell color in CuemiacTreeView.__get_*_for_cell() for category headers, and I need to reset it for normal match entries.

And basically the colors I choose should actually be the default colors If I'm not totally off? Somehow I just fail to pick up the correct color values in the two lines above, and I can't get my head around as to why...

gtk_style (in the two lines of code above) can be swiched to self.style which is a widget property that should be pointing to the current widgets style, but this gives the same result (no theming)...

I must be using gtk.Style in a wrong way. Any clues?

I wrote a short scripts that prints me the colors.
But even if I changed the theme the values didn't change.
Maybe this is a pyGTK bug?

Hmm, possible we should check with some pygtk gurus, like gjc or jdahlin maybe they know..

Created attachment 65449 [details]
Demonstrates the problem

Okay, I did some further investigations.
Finally, it turned out that the style only gets the right values, if the widget is packed. Otherwise, some default values are set.

Run python theme-color.py to see what happens if the treeview is not packed, and add a random argument to the call above to see what happens otherwise.

Created attachment 65450 [details] [review]
Workaround to display the correct background

This patch applies the colors after the widget has been packed. Therefore, the background colors are those specified in the theme. But the text color of the categories still remains black. I guess this problem refers to all custom widgets.

I don't think that leaving the text color of the categories black is a problem if the background remains grey. Theming problems apears only when the background or the foreground is themed.

It should still be a goal to make sure that the theme colors are used so that this dialog doesn't stick out like a sore thumb. But as someone who gets hit by this problem *alot*, yes, a suitable make-it-work-for-now workaround is to set the background whenever the foreground is set, and to set the foreground whenever the background is set.

Because under the right theme conditions this makes a large part of the deskbar impossible to use, I'm increasing the severity on this one.

Err, does that mean the workaround proposed by seb can be applied in the meantime ?

If it makes it ugly but usable, it's a good workaround as far as i'm concerned :)

BTW, with the invisible text in the result list, it appears it's possible to accidentally run commands thinking they'd be something else like a URL. Not fun :)

I think I ran into something related to this problem. Sebastian mentions that the theme only is correctly set if the widget is packed.

I discovered that widget.style starts out as the default gtk style (gray and dark blue) until the widget is mapped, at which point the correct theme is set in .style.

I have found two ways to compute the style correctly.

1) Connect to the "map" signal of the widget (note that in this case CellRenderers are not widgets but just gobjects) and then apply the sytle in that that signal handler. And as the last thing in the handler source_remove the id of the handler.

2) Connect to "notify::style" on the widget. This has the added benefit of picking up theme changes.

I think we should use 2) somehow. Maybe connecting the cellrenderer to "notify::style" on the treeview somehow. There is an example of this in deskbar/ui/cuemiac/CuemiacHeader.py.

Polling to see wtf ?
Should we apply sebastian's workaround, or mikkel do you have a real fix ? (or workaround ?)

Polling to see wtf ?
Should we apply sebastian's workaround, or mikkel do you have a real fix ? (or workaround ?)

grdb (and more recently xchat-gnome) extract the gtk colors via the following code:

> GtkWidget* w;
> w = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> gtk_widget_ensure_style (w);
> theme_colors[0] = w->style->text[GTK_STATE_NORMAL];
> theme_colors[1] = w->style->base[GTK_STATE_NORMAL];
> theme_colors[2] = w->style->text[GTK_STATE_SELECTED];
> theme_colors[3] = w->style->base[GTK_STATE_SELECTED];
> theme_colors[4] = w->style->text[GTK_STATE_INSENSITIVE];
> gtk_widget_destroy (w);

then catching and updating those colors on theme change:

> g_signal_connect (G_OBJECT (panel), "style_set", G_CALLBACK (style_set_callback), panel);

This helpful at all?

Yes Jeremy. I did some related work lately using some theming tricks, and I think I know how to fix this now (very close to what you describe). Now I just need some time :-) (unless somebody else grabs this bugger before me..?)

I just commited a fix to cvs head. Please verify, and reopen if necessary.

Cheers!

The fix reached Ubuntu edgy, it works fine. Thanks a lot.