GNOME Bugzilla – Bug 731872
EWebView: Use named colors from themes
Last modified: 2014-11-12 10:44:06 UTC
Created attachment 278707 [details] Screenshot of the problem After the rewrite Adwaita doesn't use "background-color" anymore to specify the background color of ".entry" widgets. Evolution is however still trying to use this color which results in a black background color for the web view. A similar problem occurs with the font color. Adwaita now relies on inheritance for that, Evolution only uses the ".entry" class. I've talked to the designers about a patch to add those colors back to ".entry" in Adwaita, but they would prefer to keep it clean of app specific hacks. They suggested using named colors in Evolution instead. So I've written a patch for Evolution to do exactly that and it fixes the issue. I've tested the patch with a few different themes and it was working quite well with all of them. I've also tested the patch with gtk 3.12 and it worked there as well.
Created attachment 278708 [details] [review] EWebView: Use named colors
Review of attachment 278708 [details] [review]: Thanks for a bug report and patch. Is this finally a reliable way to get to theme colors? Evolution suffers of this since the CSS was introduced, the themes usually define only an image for a background, with no fallback color, which results in a black background in a mail preview and elsewhere. You can find multiple bugs like yours in bugzilla with more and more workaround of this unreliability of themes. ::: e-util/e-web-view.c @@ +579,3 @@ state_flags = gtk_widget_get_state_flags (GTK_WIDGET (web_view)); + style_context = gtk_widget_get_style_context (GTK_WIDGET (web_view)); + backdrop = !!(state_flags & GTK_STATE_FLAG_BACKDROP); I'm always afraid that (in some future?) the compiler gets that smart that it'll optimize "!!" into "", which is basically equivalent, thus I developed a habit to not use it. ::: em-format/e-mail-formatter.c @@ +615,2 @@ rgba = &class->colors[E_MAIL_FORMATTER_COLOR_HEADER]; + gdk_rgba_parse (rgba, "#000000"); What is this change good for? I would skip this chunk if you do not mind.
I also tested the patch on older themes and it seems to mostly work (some themes do not define these colors, thus there is left the grey color for headers background. For example Cologne theme works better without the patch (the orange background is read properly from the theme), but it is not read without the patch at all, thus it's left grey. On the other hand Smoothy-Black theme is unusable without your patch (whole preview panel is black, background and foreground, only links are visible in the text). To make it clear, the situation is better with your patch than without it.
(In reply to comment #2) > Is this finally a reliable way to get to theme colors? Well, I wouldn't say that themes are required to specify these colors but many of them do, since other applications seem to rely on those colors being present as well. And for those themes that don't specify the colors, there still is some relatively sane fallback. > + backdrop = !!(state_flags & GTK_STATE_FLAG_BACKDROP); > > I'm always afraid that (in some future?) the compiler gets that smart that > it'll optimize "!!" into "", which is basically equivalent, thus I developed a > habit to not use it. It should work even without the !! since there are no other binary operations afterwards, I just added it for "correctness". > ::: em-format/e-mail-formatter.c > @@ +615,2 @@ > rgba = &class->colors[E_MAIL_FORMATTER_COLOR_HEADER]; > + gdk_rgba_parse (rgba, "#000000"); > > What is this change good for? I would skip this chunk if you do not mind. It adjusts the initial value of E_MAIL_FORMATTER_COLOR_HEADER to match the fallback color used when no color is defined. I just copied the initial values as fallback colors, but when testing I noticed that there was gray text on gray background, so I changed the E_MAIL_FORMATTER_COLOR_HEADER fallback color to black and adjusted the initial value accordingly.
Ah, I see, my fault. Thus I simply changed only the '!!X' to 'X != 0' and: Created commit 74366fc in evo master (3.13.4+) [1] Created commit 5f19760 in evo evolution-3-12 (3.12.4+) [1] https://git.gnome.org/browse/evolution/commit/?id=74366fc
*** Bug 733628 has been marked as a duplicate of this bug. ***