So, we’re attempting to follow this advice for a couple of OpenSolaris applications we’re working on.
It works fine for the hicolor icons, but the advice for themes that want to over-ride them is rather vague: “You can also provide icons for other themes in here [$pkgdatadir/icons], by installing them into a subdirectory for that theme.”The question is, who’s responsible for installing them? The theme or the app? Seems to me there are problems either way.
If the theme installs them, first it has to find out where that app installed its hicolor app-specific icons. It will usually be /usr/share/appname/icons/hicolor, but there’s no guarantee about the value of $pkgdatadir for any particular application.
Once over that hurdle, the theme is now stomping in the application’s territory. At best, uninstalling the app will leave a $pkgdatatdir/icons directory on your disk, containing a bunch of icons that aren’t going to be used any more. At worst, the app uninstall might just lazily blow away the $pkgdatadir directory altogether, wantonly deleting files that were installed by another package (the theme).
On the other hand, though, we surely can’t expect each app to be responsible for installing icons for every theme that wants to override them. Distros can of course patch those apps downstream with their branded icons du jour, but that will soon become cumbersome when there are more than two or three such apps. And independent theme artists, such as those who contribute to art.gnome.org, don’t have the luxury of patching any apps at all. So their themes would never be able to override app-specific icons.
So what to do? The more I work with themes, the more I wish they’d all go away and we’d just use a single, identifiably-GNOME look-and-feel like the grown-up desktops do 😛Â
Huh? The application either uses $prefix/share/icons or $prefix/share/$appname/$subdir. It’s not something that changes over time or between bugfix releases. If a theme author wants to override the icons he just points his theme to that dir. For apps that keep icons in $prefix/share/icons it’s a non-issue if a theme provides icons for an application you don’t have. For $prefix/share/$appname just package the app icons into a separate package so that it can depend on the app being installed. Please keep in mind the latter is more often used when the app itself provides more than one set of icons (say one for oxygen, one for gnome and one for hicolor).
Well, you might think it’s a problem, but so far all the affected app and theme maintainers I’ve mentioned it to have thought it was a bad idea…
Our theme maintainer has decided he’d rather install the app-specific icons into the global theme directory for now anyway, so problem solved for this release (until there’s an icon name collision, which probably won’t be anytime soon…)
Er, you might think it’s *not* a problem 🙂
Apps that install icons to $prefix/share/icons generally adopted the idea of prefixing custom icon names with app name so it’s not a bigger problem than conflicting files in $prefix/bin