GNOME Bugzilla – Bug 647599
user-theme extension: support globally installed extension
Last modified: 2011-05-02 16:33:22 UTC
I want to create rpm packages for custom shell themes, but contents from RPM packages can't be installed on user's home folder. The solution is quite simple: Allow user-theme to use themes that are installed in /usr/share/somewhere (maybe /usr/share/gnome-shell-themes or something like that)
The right directory to use is /usr/share/themes/<foo>/gnome-shell. Actually, we should move even the default theme to /usr/share/themes/Adwaita/gnome-shell/, and then we can drop the user-theme extension. (It would add a dependency on gnome-themes-standard, but I don't think it is a problem)
(In reply to comment #1) > Actually, we should move even the default theme to > /usr/share/themes/Adwaita/gnome-shell/, and then we can drop the user-theme > extension. That probably won't happen for 3.0.1, and I think the extension should support this, so it would be possible to create packages for themes before 3.2 or later version with theme support is released.
The way GNOME Shell works is that almost any change to the code requires changes ot the CSS as well. There isn't idea that you can customize some specific stable set of CSS classes and get a new theme for GNOME Shell. And there certainly will not be any such guarantee for 3.2 => 3.4 either. On the other hand, the /usr/share/themes mechanism implies that there are set of equal themes, and that the standard theme is just one among equals. And that there is some advertise standard about how you make a working theme. There are only two ways I see themes as practical: 1) - They are installed by the user - The user knows that the they've installed some customization to GNOME Shell that changes the experience away from the GNOME design. - The customization declares compatible versions - The user knows customization extensions might be incompatible with newer GNOME Shell and has the expectation that upgrades to GNOME Shell may disable customizations until the customization is updated That is, themes as *extensions* - presumably distributed by the GNOME extension website. 2) They are done as distribution patches to GNOME Shell and the distributor updates and tests the patches when shipping a new version of GNOME Shell. So, the standard GNOME Shell CSS will not be installed in /usr/share/themes. It doesn't make sense.
Well, currently (for the extension), I'd suggest adding a standard header that each theme will need to have, with a metadata about version compatibility, theme creator and such GUIs such as gnome-tweak-tool could use this info as well. I think a different format for themes is better then themes as extensions because Currently, every extension that is installed, even globally, is enabled by default. Having multiple themes installed globally when each theme is an extension will cause some stage side-effects from collision between themes, and it's not clear which one will actually work. Users might want to install themes globally so they will be available to all users of the machine (or, distributions might want to ship themes in packages) and users should be able to select which theme to use for each user separately. This can't be done (nicely) with the current mechanism of extensions. I think the way it is implemented now (with the user-theme extension) is the right way to go, and I think this functionality should be merged to the shell. I propose this metadata format for themes (in the top of the CSS file): /* Gnome Shell Theme Name: Theme Name goes here Version: That's the theme version, eg. 1.0 Supports-shell: 3.0.0.2 (that's the version of the shell this extension supports) */ That's the minimal format. Other fields will be ignored by the shell, but can be used by GUIs (such as gnome-tweak-tool). Fields like that might be author name, theme license, theme website, author website, recommend GTK theme to use with the theme, recommend icon theme to use with the theme (GUIs will enable the user to automatically enable the recommended themes if the users wants that), and more. Another way to implement this would be to add a field to metadata.json that will define if the "extension" is a real extension or a theme, and if it's a theme it should either not be enabled by default or disable other enabled themes. (I think the first suggestion is better). When the shell is updated and the enabled theme becomes incompatible, a notification or an error dialog should be shown to the user and explain why the theme doesn't work.
Created attachment 185933 [details] [review] Support globally installed themes Patch to support globally installed themes in the user-theme extension.
Created attachment 185935 [details] [review] Support globally installed themes Better.
Comment on attachment 185935 [details] [review] Support globally installed themes Will send a better patch shortly.
Created attachment 185938 [details] [review] Support globally installed themes Okay, this one works.
Review of attachment 185938 [details] [review]: ::: extensions/user-theme/extension.js @@ +32,3 @@ + else + { + _userCssStylesheet = '/usr/share/themes/' + _themeName + '/gnome-shell/gnome-shell.css'; Use GLib.get_system_data_dirs() here. And maybe add global.datadir (so jhbuild installations work).
Created attachment 185969 [details] [review] Support globally installed themes (try 2) Fixed.
Review of attachment 185969 [details] [review]: Looks good!
the status on the patch is accepted-commit_now, so, can you please commit it?
bug #647386 also needs to be fixed if reverting to the default theme is to be supported.
Comment on attachment 185969 [details] [review] Support globally installed themes (try 2) Turns out that it was slightly incorrect (you cannot concatenate an array to a string). Fixed and pushed to master. Tell me if you want it on gnome-3-0.