Human theme makes bad GTK widget class assumptions

Here's the most relevant upstream bug on this issue:

http://bugzilla.gnome.org/show_bug.cgi?id=534731

Maybe this is related: I use the Ubuntustudio theme (colours and controls) and banshee 0.99.3 (from the ppa mentioned on the website). When I move the cursor over an item in the left hand side list of playlists, the item disappears. It reappears again when I remove the mouse cursor from it. I guess this is related to theming as well, the foreground colour is probably changed to white on mouseover. Since my banshee version is not in Ubuntu yet, I'm not sure if my report is appropriate here.

As the app is using a non-standard class widget how can we create a theme which works? Firefox, gnome-control-center, and vlc all have these problems (it has become apparent when switching to the dark theme). The only way I know how to work around this is to apply the correct theme info to these special subclasses but that is really a hack. The correct way to do this would be to ask apps to follow the rules and don't hack together widgets from classes which were not intended to be hacked thusly.

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.

No, it means that if the app used normal gtk classes this problem would not occur :-) In your example of "bad" theme code we set the bg[SELECTED] color to the color value of @selected_bg_color which only makes sense, really. The fact that one has to explicitly set it is bad but that is not a problem with the theme itself.

In any case, we are going to use murrine instead of ubuntulooks/clearlooks but my guess is that the same problems will occur.

"The correct way to do this would be to ask apps to follow the rules and don't hack together widgets from classes which were not intended to be hacked thusly."

I'm sorry, but what? Are you saying that it's wrong to write custom widgets? Are you saying that everything you could ever want to accomplish can be accomplished using only the built in classes? I'm a bit surprised that a custom widget derived from GtkWidget would illicit that comment.

My example of "bad" is not setting bg[SELECTED], which just sets it to the defined color constant, it's setting the "treeview" hint on the Clearlooks engine. This causes Clearlooks to do something special with the bg[SELECTED] color (make it lighter).

Because of this hint, two separate background selection colors will be evident in GTK applications, which is not good.

Why not just make selected_bg_color lighter?

My point is that the only apps which have these problems are ones that create their own custom widgets. Trying to play around with the few colors that we can define just makes things unbelievably hard for the theme developer to do something different than the norm (light grey bg with dark text). I have nothing against custom widgets, I just want them to follow the rules on using colors so that the custom widget doesn't make themeing in general impossible. Finally, the best idea would probably be to include a couple more colors (KDE did this in the switch from 3 to 4)

My point is that there could be 1000 custom apps out there doing similar things. Your solution is to ignore them. You have to realize that there are some extremely serious issues regarding GTK theming, and as a theme designer, you need to respect that. Just because you want something to look a fancy certain way doesn't mean that's a good idea because you obviously run into issues like this.

Everyone wants GTK to be prettier, easier to theme, etc., but we'll never get that with GTK 2.0, and that needs to be kept in mind, respected, and never abused, *especially* in the default theme shipping with such a popular distribution. At the end of the day, this selfish decision hurts the upstream applications that provide value to your downstream distribution.

We do the /exact/ same thing for using theme colors in our widget as the GtkTreeView, but we get different results because the /theme/ gives us different colors for the /same/ "query" because our GObject class hierarchies are different (and there is _nothing_ wrong with this, it's a central idea of the /framework/ that is GTK and OOP in general). It seems that this is hard for you to understand, so I have introduced an insane but manageable hack in our application so at least users won't be blaming us upstream for downstream deficiencies. But this only works for /our/ application. Try to imagine the issue in the larger scope of potential ISV and other third party applications out there.

Other themes seem to understand the limitations here, I would think Ubuntu would follow suit for its default themes.

I also want to point out that I feel so strongly about this issue not from a purely cosmetic point of view, but from a usability/accessibility point of view. We've had a few users complain that because of this bug, the background selection color was too dark and caused contrast issues with the text color, making our custom view hard or stressful to read. That's not cool.

Close this if you want, we at least shouldn't hear complaints upstream now (http://svn.gnome.org/viewvc/banshee?view=revision&revision=4112), but I'm sure there are many other apps out there you don't and won't know about that will suffer the same or similar problems.

gtkrc change fixes this bug