GNOME Bugzilla – Bug 110315
gnome-theme-manager doesn't take the union of all paths
Last modified: 2007-11-11 20:04:20 UTC
Installing, say, a Metacity theme into ~/.themes hides all other themes of the same name installed elsewhere on the system. I think this is because the theme manager is not taking the union of all themes named in such a way: if there is found a ~/.themes/foo, the /usr/share/themes/foo entries are ignored. Desired behaviour would be for all such themes to be found, and if a theme with the same name and of the same exists in more than one spot, the ~/.themes entry will override it. For more information see http://bugs.debian.org/188236
Yeah, I noticed this when playing with theme code but there's not a chance of me trying to fix it because it's hard. So you say that duplicate themes should be shown unless 2 themes that have the same name are actually the same theme. (Working out if it's the same theme is tricky.) Usability-maint, any comments on this?
I think that themes which have the same name should all be shown, unless the same name + same type (i.e., foo's GTK theme) is present in both ~/.themes and /usr/share/themes, in which case the ~/.themes version of the GTK theme should override the /usr/share/themes. i.e., it doesn't have to be the same theme, just the same name.
Personally I don't really see much point in checking for duplication... if we're not happy with the current 'override' approach, I would just show all the themes, and indicate which was the local version somehow. Worrying about local, identical copies of a system theme seems like a fairly obscure edge case to me (why would you bother installing one?) Another approach would be to check for existing duplicates when you installed a new theme, and ask whether you wanted to over-ride the system one or rename the local one. Renaming could be tricky to do well, though, it would presumably require parsing/modifying some of the files as it was installing them. (Such a scheme would obviously only work if you installed a theme via the GUI anyway, but maybe it's not unreasonable to leave commandline users to their own devices...?)
*** Bug 155977 has been marked as a duplicate of this bug. ***
Created attachment 34233 [details] Overlay locations in the theme prefs I have a similar mockup for the background capplet, so I just modified it since I think it might work better for this than the backgrounds. I thought that separating the two themes might give better access to the themes that people actually wanted. Merging the custom themes and the system themes requires you to search through all themes for the themes you created. Maybe I'm wrong but it seems that if a user has gone to the trouble of making themes they would want to get quick access to them. Overriding installed copies creates odd interactions to get the original copy back; you'd have to delete the custom one? Plus a host of other weird issues like that. Asking about overriding seems like extra questions that people won't really understand. So just adding in new themes even if they are duplicates seemed to be the simplest way to go for the user and for the capplet. ;-) So here's how it works, when there are only system themes installed (i.e. no ~/.themes) then there is no separation bar. When there is a custom theme installed the we show the separation bars. bug 105452 describes a remove button that is missing and needs to be added so that people can delete the custom themes. Oh and the wording isn't right, its a little confusing right now.
How about: * "Custom Themes" -> "My Themes" or "<user>'s Themes" * "Installed Themes" -> "System Themes", "Preset[s] [Themes]" or "Predefined Themes" I prefer the first alternative for both. Once the user has created the theme, how is it named, and what description will it get? Preferably, the user shouldn't be required to provide those details himself. I suggest some rule like: "<user>'s <ControlThemeName>-theme", or something equiv. So, for example, if I created a theme with "Bluecurve" as the theme for controls (buttons, etc), it would be called "Vidar's Bluecurve-theme". Description could default to "A theme composed of Bluecurve, Crux and Gartoon", in the order <controls> <windows> <icons>. I would suggest some other things I had on my mind, but gnome-theme-manager now manages to crash consistently every time I start it (Ubuntu Hoary / GNOME 2.8.1). I'll come back later when I get it running.
Still the same
This can also happen in any theme where the name is not guaranteed to be unique identifier, such as in metacity and icon themes were the name is stored in a description file. I can't see any obvious solution to this, apart from perhaps just adding a number in brackets to the end of each conflicting theme name.
The original bug should be fixed in 2.20+. The question remains whether we want to distinguish between system and user-installed themes in some way, but to be honest I don't see why we'd want to do that, and as Calum noted it's pretty much an edge case, anyway. Closing, unless somebody complains...