GNOME Bugzilla – Bug 664364
Mutter uses ugly fallback in GNOME Shell when Ubuntu's Ambiance theme is used
Last modified: 2011-12-13 16:55:46 UTC
Created attachment 201693 [details] [review] 04-ubuntu-patch Originally reported at https://bugs.launchpad.net/bugs/800315 When Mutter/GNOME Shell sees theme elements it doesn't recognize, it displays an ugly theme (I guess as a warning to developers or packagers). This breaks Ubuntu's Ambiance and Radiance themes which use the "padding" and "shadow" elements. For Ubuntu 11.10 and GNOME 3.2, Ubuntu just used the attached patch but you may wish to solve this problem a different way. Screenshot of ugly theme: https://launchpadlibrarian.net/77478136/gnome-shell-ambiance-window-theme.png
Created attachment 201694 [details] screenshot-after-patch And this is a screenshot after the patch has been applied.
> This breaks > Ubuntu's Ambiance and Radiance themes which use the "padding" and "shadow" > elements. That seems rather backwards to me. If Ubuntu embraces and extends the metacity theme format, it is mutters fault ?!
Created attachment 201712 [details] [review] theme-parser: Allow, but ignore other toplevel tags
It should at least warn, if you ask me.
Warn who and how? I don't think we need to warn users, just developers. Would printing a message to .xsession-errors be sufficient?
I consider the current behavior a feature, which at least helps theme developers to catch simple typos - a warning kind of works as well, but requiring theme authors to digg through .xsession-errors is considerably more effort. To be honest, I find it rather frustrating that we go through great lengths to make theme additions in a backward-compatible way, just to see it kicked out because Ubuntu considers *our* theme format something they can extend at will. So my preferred solution would be to close this NOTGNOME, which would leave Ubuntu with the following options to fix this properly: - properly fork the theme format - if compiz looks for compiz-1.xml first before falling back to metacity-2.xml, the latter could be compatible with upstream, while Unity would still use the extensions (while maintaining compatibility with upstream themes) - file upstream patches to add support for properties they feel are missing from the theme format (no idea what "padding" is used for, but "shadow" looks like something useful to support)
We have no way of knowing whether some unused thing in the theme format is optional, or essential to make the theme usable. (I sort of regret doing the extensibility in metaacity-theme-3.xml as a strict version rather than a named-extension mechanism, but on the other hand, I don't really see it reasonable for theme authors to deal with arbitrary subsets of features that each wm may or may not support. And I don't see going to a metacity-theme.xml at this point - the theme format has other issues discouraging pushing it too far.)