GNOME Bugzilla – Bug 534731
Wrong selected-item color with some GTK themes.
Last modified: 2008-06-04 23:10:11 UTC
Please describe the problem: When using certain GTK themes (such as Human, Human-Murrine and Human-Clearlooks) the color of selected items is inconsistent with the rest of the theme. This results in a dark orange selection background in the library/playlist selector, and a dark brown selection background in the music library/browser. It's merely a cosmetic annoyance, and I have long found a workaround for my personal themes, but there are many GTK themes which have more than one overall selection background color, and are affected by this. Steps to reproduce: 1. Use the Human GTK theme (Ubuntu's default) 2. Start Banshee 0.99.2 Actual results: The colors of selected items are inconsistent with the rest of the theme. It uses a combination of dark orange and brown. Expected results: I would expect the selected items to use the colors defined by the theme, which is a lighter shade of orange. Does this happen every time? Yes. Other information:
screenshot, please?
(In reply to comment #1) > screenshot, please? > Here's a screenshot reproducing the problem, sorry I didn't add it before. http://img79.imageshack.us/img79/6572/screenshotms1.png
We do use the colors defined by the theme, but there is clearly some inconsistency here. Part of the issue is probably that the colors are defined differently in the Human theme depending on the base class of the widget, which is a *horrible* idea. Horrible because we use the standard GtkTreeView on the left, but our own custom cairo based view that is not based on the GtkTreeView on the right, so that would explain the inconsistency of the colors between the two views (left, the source browser, and right, the collection browser). Here's a long rant I wrote about bad GTK themes doing just this: http://abock.org/2007/07/02/suboptimal-theming-in-gtk/ Because of some other theme issues, we then take the base selection color and shade it slightly so we can create a subtle gradient to emulate what most themes do. That could be another part of the inconsistency, but not as bad as the fact that Human probably defines two separate colors for the selection background - one for normal widgets and another special cased for GtkTreeView based widgets. That's the true atrocity. At the end of the day, this is a theme bug.
Sure enough! Straight from the gtkrc of Human, there's this style: ... style "clearlooks-treeview" { bg[SELECTED] = @selected_bg_color engine "clearlooks" { hint = "treeview" } } ... It sets the background to be the normal selected BG color, then appears to pass a hint to the Clearlooks engine to do something special because the style is applied to a GtkTreeView. How classy. Sure makes me feel second class.
Created attachment 112103 [details] Attached screenshot from comment #2 Attaching the screenshot linked in comment #2 so all data is preserved.
I've filed this issue downstream with Ubuntu: https://bugs.launchpad.net/ubuntu/+source/human-theme/+bug/237261
Okay, I've done some nasty hacking around this issue at the Banshee level so at least this will appear to be fixed in Banshee. It's still a huge issue in the Human theme itself, but as I'm viewing this bug as a usability/accessibility issue I felt it necessary to work around upstream. http://svn.gnome.org/viewvc/banshee?view=revision&revision=4112 I'm marking this FIXED, but the downstream Ubuntu bug is still extremely relevant.
btw. bug #453499 is the gtk-engines bug about all this. Aaron, I do agree with you that all fg/bg and text/base pairs should always match (and it is rather annoying that GTK+ is mixing up the pairs in places). But I cannot agree with some other things you say. It seems to me like you are saying that special casing anything for certain widgets in the theme is broken. This is one of the core features of the GTK+ theming system! Now, what you are trying to do is to make one widget, look like a stock GTK+ widget. And to get that working the theme will of course need to know what you are doing. In GTK+ what you need to do is to at least get the correct GtkStyle for your widget, and this can be easily done with gtk_rc_get_style_by_paths. This function is the reason that the "hint" exists in Clearlooks, as, when you use it, Clearlooks will know that you are trying to fake a GtkTreeView. The widget may in reality be an ETree widget, but the engine does not need to care about that.[1] Is it really too much to ask application developers to use gtk_rc_get_style_by_paths or something similar? [1] A problem that still exists are style properties.
I just want to thank the developers here for resolving this issue upstream. Being that Ubuntu's geared towards non-technical users, minor annoyances like this would have put users off of this great media player (since they wouldn't know how to fix them). Also, There was an workaround for this issue in themes similar to Human (I've been including it in the releases of my Clearlooks-Colors and Murrine-Colors themes since the first banshee-1 alpha release), but it causes some bad side effects in other applications. As a theme creator, now I don't have to include such unreliable workarounds, so again, thank you for resolving this issue, and I hope to see it in the next release!
@Benjamin: Thanks dude. TBH, I completely forgot about gtk_rc_get_style_by_paths, so my original fix was a more manual, round about way of doing the same. I've reverted my earlier fix and replaced with gtk_rc_get_style_by_paths, which is much cleaner obviously. My point in the LP bug is mostly about the color inconsistencies, so I'm glad you agree here. Regarding using class names for applying styles, I maintain this is a horrible idea, and would prefer to see a standardized and documented hint system [1], since it would be more obvious and easier to use, but it would still just be a bandage for poor theme support in GTK+ 2.0. I guess it's all moot at this point other than it's clear that many people are frustrated - here's hoping we get proper theme support in GTK+ 3.0. @Victor: glad to help, thanks for the kind words. [1] I think I described my dislike toward the class based paths and desire for a hint system in more detail here: http://abock.org/2007/07/02/suboptimal-theming-in-gtk/