GNOME Bugzilla – Bug 671796
Style breakage for (light) window decorations
Last modified: 2012-03-10 21:12:27 UTC
A recent GTK+ update broke "normal" (read: not dark) window decorations. Given that our usage of GTK+ is rather special, I think it is acceptable to fix the problem in mutter.
Created attachment 209411 [details] [review] frames: Explicitly initialize style contexts We were relying on GTK+ emitting GtkWidget::style-updated during widget initialization to create the GtkStyleContexts used for window decorations. A recent GTK+ update broke this assumption, so do the necessary initialization ourselves.
Created attachment 209412 [details] Screenshot of the issue
Review of attachment 209411 [details] [review]: Are we damn sure this same bug won't affect other GTK+3 applications? If we are, then go for this patch. If not, put back the old behavior in GTK+.
Review of attachment 209411 [details] [review]: OK, between these references: https://bugzilla.gnome.org/show_bug.cgi?id=662023 http://git.gnome.org/browse/gtk+/commit/?id=5d579811843f81db9866ac81afc5297f776cfb3b It's clearly our fault. Go for it.
Attachment 209411 [details] pushed as 7253a75 - frames: Explicitly initialize style contexts (In reply to comment #3) > Are we damn sure this same bug won't affect other GTK+3 applications? Damn sure? No. I can imagine that "applications" that create a window, never actually show it (but try to trick GTK+ into thinking it was) and rely on the emission of a signal to control their manually managed styles (rather than taking the one from the widget) *might* be affected as well. Or in other words: I consider our GTK+ usage crazy enough not to never ever expect breakage :-)