GNOME Bugzilla – Bug 640465
border color seems to affect fill for .dash-search-button {}
Last modified: 2011-02-16 01:06:50 UTC
Created attachment 179220 [details] blue buttons, even though the should be semi-opaque white I was going to tweak the shading for the search buttons but found out the border color seems to affect the fill on those buttons: diff --git a/data/theme/gnome-shell.css b/data/theme/gnome-shell.css index 65aaaf2..92c0c6a 100644 --- a/data/theme/gnome-shell.css +++ b/data/theme/gnome-shell.css @@ -452,7 +452,7 @@ StTooltip StLabel { background-gradient-direction: vertical; background-gradient-start: rgba(255, 255, 255, 0.2); background-gradient-end: rgba(255, 255, 255, 0); -/* border: 1px solid #808080;*/ + border: 1px solid blue; border-radius: 10px; height: 32px; width: 300px; recolors the whole button blue as demonstrated by the attached screenshot.
Created attachment 179233 [details] [review] tests: show off translucent gradients Right now border color is leaking through. Demonstrate that.
Created attachment 179234 [details] [review] StThemeNodeDrawing: Ignore border fill in interior We need to be careful to ignore any preexisting color information in the interior of the node when filling it with the background color, since the border color may have leaked into the interior and the background color may be translucent.
Created attachment 179235 [details] [review] StThemeNodeDrawing: fill background behind translucent gradients If a background gradient isn't fully opaque, then we need to first fill in the background color so the border color doesn't leak into the interior.
*** Bug 641839 has been marked as a duplicate of this bug. ***
Review of attachment 179234 [details] [review]: I had planned to review that, but somehow forgot about it - sorry for that. Looks good.
Review of attachment 179235 [details] [review]: OK.
Review of attachment 179233 [details] [review]: Sure.
coolio
So drago01 noticed attachment 179235 [details] [review] causes rendering regressions in the alt-tab pop up
Created attachment 180949 [details] [review] Revert "StThemeNodeDrawing: fill background behind translucent gradients" This reverts commit b4ec342d0603f1dc39cdadec62d9dcd7ec49f17d. The alpha > 0 checks should actually be alpha < 255 for the commit to make sense as designed. The design isn't right either, though, since we need to preserve the translucency in translucent gradients, not block it with a solid color fill.
Created attachment 180950 [details] [review] StThemeNodeDrawing: clear out node interior before filling pattern If we aren't going to fill the content area of the node with a solid background color, then we need to clear it of any artifacts left over from drawing the border.
Review of attachment 180949 [details] [review]: Not sure I would have gone with the "revert + fix" rather then just "fix" but there is nothing wrong with that.
Review of attachment 180950 [details] [review]: Looks good (and fixes the problem I saw) but seems like to introduce a similar issue elsewhere, which we could either fix later (in both code paths) or fallback to always use the cairo path in this case as you suggested on IRC. ::: src/st/st-theme-node-drawing.c @@ +827,3 @@ + * background image, because it either always fills the entire area + * opaquely, or we draw the solid background behind it. + */ I am not sure about this part, this sounds like it will cause the same problems again when the background image is *not* fully opaque. But as noted on IRC we do the same in the cogl path, so we should either change both or maintain consistency.
Given every change has the potential to break status quo, let's deal with the background image case later if/when we run into it.