Comment 4 for bug 237261

Kenneth:

You create a theme which works by not special casing colors to certain widget classes. While it might be nice to do, unfortunately the GTK 2 theme system is extremely limited and is a layer of hacks.

The argument that no one should write widgets not derived from standard GTK widgets is amusing, and assuming they are "hacked together" is more so. GTK provides a framework for writing widgets and it's perfectly acceptable and reasonable to do so. As a theme writer, you have to respect that the GTK theme system is very limited and fragile to play nice with other applications.

Pretend I was an ISV and I have a large application that I am actively working on porting to Linux and we have a number of custom widgets. Say we're a medial company and we have lots of medial related widgets - something GTK would rightly never provide. When we find that our application is inconsistent and possibly unusable in these subtle theme related ways, it can easily give a bad impression of the platform we're trying to target and could instill doubt about the choice.

At the application level the best thing a widget developer can do is respect how color pairs are to be used. For instance, foreground + background, text + base, and so on. If a theme breaks these pairs or introduces inconsistencies, there's no way we can really address that.

For the Clearlooks specifically, they at least appear to support somewhat standard "hints", which is what Human sets in this case. One possible, but not likely, workaround at our level would be to force apply this hint on our widget. But that's a dangerous game - for one it assumes the theme engine will always be Clearlooks, and the right version of Clearlooks at that.

There are also other hacks we can attempt to apply on the widget, but again there is no guarantee that they'll be respected or work for a specific theme. Going down this path means the widget should be aware of and cater to every possible theme out there.