GNOME Bugzilla – Bug 46238
sidebar background does not respect gtk theme
Last modified: 2004-12-22 21:47:04 UTC
The sidebar backgound color/image does not respect GTK theme. * REPRODUCIBLE: Always * STEPS TO REPRODUCE: 1. Apply GNOME theme in nautilus. 2. The background of the sidebar does not follow the background property of the actual GTK theme. The background is a light blue. * ACTUAL RESULTS: see above * EXPECTED RESULTS: I would expect that the GNOME theme in Nautilus would use all the gtk theme values and not use any of it's own colors/patterns unless manually customized. The current background of blue, does not look very good with a theme like AbsoluteE which is dark green. Latest Ximian GNOME Nautilus PR3 Redhat 7.0 ------- Additional Comments From andy@eazel.com 2001-02-01 22:12:54 ---- I think he is right - we should enable Nautilus sidebar themes to respect the GTK theme, and configure the GNOME theme to do so. I think we should do this for 1.0 because it's really simple to do and test, and was really a blunder to not do this initially. ------- Additional Comments From ramiro@fateware.com 2001-02-10 03:22:38 ---- The largest chunk of work would be to make NautilusBackground have a noop mode where it does nothing and lets the underlying gtk theme machinery do the painting. Right now NautilusBackground assumes "white" is the default. ------- Additional Comments From ramiro@fateware.com 2001-02-10 03:23:39 ---- On the other hand it fixing this means fixing many places where we violate the gtk theme. Including the icon container - since they all use NautilusBackground. ------- Additional Comments From mjs@noisehavoc.org 2001-02-24 06:32:36 ---- The sidebar would look really ugly if it were default Gtk gray. Most Gtk+ apps that have some sort of sidebar make it some other color. I suggest marking this bug WONTFIX. ------- Additional Comments From mjs@noisehavoc.org 2001-02-24 06:38:45 ---- Much like bug 46239, I do not think this is a 1.0 blocker so kicking into 1.2. ------- Additional Comments From eli@eazel.com 2001-03-26 11:13:17 ---- QA Assigning to self. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:58 ------- The original reporter (dbl@dittos.yi.org) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org.
Changing to "old" target milestone for all bugs laying around with no milestone set.
*** Bug 74817 has been marked as a duplicate of this bug. ***
Setting dependency on 41041 and marking future. Darin: Can this be fixed for 2.0 or should this be something that should be taken up post 2.0. CCing louie at his request.
Changing title to better reflect the bug.
Should this be 'fixed'? I agree with mjs here that getting it to use the gtk+ theme color (which in 90% of cases is grey) would be kinda ugly.
Yes this should be fixed since it's an accessibility issue. However the way to fix this is not to fix the current sidebar, but to instead replace it with a more standard design like the evolution/mozilla/IE sidebar. see bug 74821. Just for the record, everything should be themed by gtk, so that all apps are accessible and look consistent with each other.
Because of the a11y implications of this bug, I'm marking it up to high. Please feel free to persuade me otherwise, but be aware that I'm assigning man, myth, legend Dave Camp to work on it, which helps my case ;)
I'm on this. Sorry for not assigning it to myself before. I'm basically sweeping the code to remove the bits that set hardcoded colors with EelBackground. I also want to modify the GNOME theme so that it sets as few colors/images as possible.
Sheesh. We get a white background in the sidebar because a null color specification ends up in eel_gdk_color_parse_with_white_default(). I'm changing the code in eel_background_get_pixmap_and_color() to return a color from the widget's style if there is no color specification.
Fredrico, can you change it so that if the user is using a pixmap theme the theme pixmap is used???
I'm attaching a first cut at patches for Nautilus and EEL. Bordoley: please file another bug if it doesn't work after this one is fixed :)
Created attachment 9955 [details] [review] Patch for EEL.
Created attachment 9956 [details] [review] Patch for Nautilus.
Created attachment 9957 [details] gnome.xml file that you need to put in /usr/share/pixmaps/nautilus/gnome/; this removes the hardcoded colors from the theme.
+ if (start_color_spec && eel_gdk_color_parse (start_color_spec, &color)) + background->details->background_color = color; + else { + GtkWidget *widget; + GtkStyle *style; Local variable declarations go at the beginning of the function, see nautilus coding styleguide. + background->details->background_color = style->bg[GTK_WIDGET_STATE (widget)]; Is it right to use the current widget state at realization time? We don't later handle state changes, so the wiget will forever be in that state. Maybe we should just use GTK_STATE_NORMAL? + background->details->respond_to_style_set = FALSE; Can't you block the signal handler using g_signal_handler_block() instead? It seems less hacky to me. Otherwise it looks good. Can you attach a screenshot of how the Gnome theme looks with it?
Frederico, I'm currently without any access to a gnome setup, so if some one else could test this with a pixmap theme, that would be cool. I think it would be cool if this worked well with pixmap themes.
Created attachment 9972 [details] Screenshot with the l33t dark ThinAndMild theme.
Fixed on CVS with Alex's comments. Let me get hold of a pixmap theme to see what happens.
The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email bugmaster@gnome.org if you have any questions. URL: nautilus-qa-maint@bugzilla.gnome.org