GNOME Bugzilla – Bug 412413
consider local gtk themes for themes
Last modified: 2016-03-31 19:05:52 UTC
It's possible to theme applications locally*. Graphics editors for example benefit from having a dark theme. Metacity only considers a global gtk theme for coloring WM decorations. This makes the 'dark apps' have a shining light window decorations. I'd appreciate if metacity would shade gtk colors taking the local themes into consideration. * `GTK2_RC_FILES=$HOME/.themes/Darkilouche/gtk-2.0/gtkrc f-spot`
If the way to have application-specific themes is an env variable like that, it would be pretty hard to implement this. I guess each app could set its theme on the app window or something then metacity could set a different theme on each window frame somehow.
After some talk on #f-spot (who really want this feature) I filed a bug against Compiz some time ago. The response now was that Compiz needs this to be implemented in metacity, as they use metacity window deco :) Anyway the bug can be found here: http://bugs.opencompositing.org/show_bug.cgi?id=933 Short version: The app would add a window manager hint containing the theme name and Metacity would read this specific theme and use it for the window(s) of this application. Any reason why this would not work? I would love to see this work!
WM hints are a much better idea than environment variables. It would require a bit of upheaval since themes are currently singleton, and obviously increase the memory footprint if you used multiple themes. The Compiz folks' arguments go over my head. What do they mean by "use metacity window deco"? They use our theme format, but not our code (at least I hope they don't, because iirc they're LGPL).
Compiz uses libmetacity-private in gtk-window-decorator IIRC.
Oh dear[1], do they? Okay, well, there's no licence issue, then. This would also be solvable by the idea that was being bounced around on the Metacity blog about GTK doing all the theming work, but that's more long-term. I have things I want to get done before I look at this, but if anyone wants to work on it I'll do my best to be as helpful as I can. [1] only because, well, "private" for a reason-- although there's an argument that it should be cleaned up and its API made public.
Created attachment 149962 [details] Metacity displaying different theme based on res_class
Sorry to revive this old bug, but I would really like to see this also. I followed the link to the compiz bugzilla but saw it was closed as "Resolved Upstream"? Also, while I'm a complete newbie and don't understand most of gtk-window-decorator.c it doesn't look like there is any room in there for anything more than a single metacity theme and looks like a good chunk of it would need to be re-factored? In any case, playing around with Metacity I did manage to tack on support for an alternate theme. And I do mean "tack on" :-) But hey, it works and it allows for a light theme and a dark theme, which I think should be enough, it also allows user configuration. Allowing an arbitrary number of themes doesn't seem like a great idea. Just too bad it doesn't work with Compiz. :-(
Nevermind my comment about gtk-window-decorator, it only took like 20 lines to enable support. Like I said I'm a total newbie. :-( I've uploaded my "hack", ugly hack I should say, at http://gnome-look.org/content/show.php?content=117340 The theme itself needs a lot of polish, but it's really just an example. I understand the current version of Metacity may not be so important anymore, but I really hope you guys keep this bug in mind while writing the next version.