summaryrefslogtreecommitdiff
path: root/gtk/gtktoolbar.c
diff options
context:
space:
mode:
authorCosimo Cecchi <cosimoc@gnome.org>2012-06-13 19:38:42 -0400
committerCosimo Cecchi <cosimoc@gnome.org>2012-06-13 20:10:41 -0400
commitad63d1b59ee5da3b0a962d6ea315c032873b6b29 (patch)
tree8398059612bce9df781fa29306adb1d871c2374b /gtk/gtktoolbar.c
parent7e37b457873f917cfc045f511a28d4e30fb6024a (diff)
downloadgtk+-ad63d1b59ee5da3b0a962d6ea315c032873b6b29.tar.gz
toolbar: don't call gtk_style_context_set_background()
GtkToolbar doesn't have its own GdkWindow to draw on (it calls gtk_widget_set_has_window(FALSE) in _init), but only an event window (input-only). Since gtk_widget_get_window() in that case will return the GdkWindow of the parent container, by calling gtk_style_context_set_background() here we're overriding the base background of the container instead of our. While in most cases this doesn't have any noticeable effect, since the toplevel GtkWindow will paint its background on top of it at the beginning of the draw cycle, when the classic window hierarchy is broken, such as when widgets are rendered through a clutter-gtk offscreen embedding, the background will become visible, which is undesirable. Fix this by having GtkToolbar not call gtk_style_context_set_background in its style_updated handler.
Diffstat (limited to 'gtk/gtktoolbar.c')
-rw-r--r--gtk/gtktoolbar.c5
1 files changed, 0 insertions, 5 deletions
diff --git a/gtk/gtktoolbar.c b/gtk/gtktoolbar.c
index 5dfa206bdc..3a389bd977 100644
--- a/gtk/gtktoolbar.c
+++ b/gtk/gtktoolbar.c
@@ -1879,11 +1879,6 @@ gtk_toolbar_style_updated (GtkWidget *widget)
GTK_WIDGET_CLASS (gtk_toolbar_parent_class)->style_updated (widget);
priv->max_homogeneous_pixels = -1;
-
- if (gtk_widget_get_realized (widget))
- gtk_style_context_set_background (gtk_widget_get_style_context (widget),
- gtk_widget_get_window (widget));
-
gtk_toolbar_update_button_relief (GTK_TOOLBAR (widget));
}