Icon names vs. emblems
jpetso at gmx.at
Tue Jun 17 03:35:32 PDT 2008
On Tuesday, 17. June 2008, Matthias Clasen wrote:
> One intriguing possibility to solve this is to use some kind of escape
> in icon names, and do something like
> which is currently not an allowed icon name (since the + is not allowed
> in icon-naming-spec-compliant icon names).
> If people think this is a good idea, here is patch that adds suitable
> language to the icon naming spec (the patch is against 0.8, since I
> couldn't find the source repository for the latest spec...).
I think I like that idea, I could see it being used for our folder icons (we
currently ship "legacy" folder-[blah] icons which should rather be "folder"
plus emblem-[blah]) and probably other uses.
As long as providing such a [base]+[emblem] icon is always optional for the
icon theme, this might work out nicely. I think the language in your patch is
not optimal yet, it should emphasize that this is mainly a feature for
themers to provide tuned versions instead of the standard overlay mechanism.
Also, what should happen if there are more emblems required by the application
(say, folder+encrypted+important+favorite)? When that verbatim icon does not
exist, will the icon engine look up folder+encrypted+important, then
folder+important+favorite, then folder+encrypted+favorite, then
folder+encrypted, then (...continue ad infinitum)?
Or will it just try once for the full name with all emblems and immediately
fall back to single icons when that one doesn't exist?
(Personally, I'd prefer the latter variant in order to save hard disk lookups
for an unprobable case.)
P.S.: Whatever happened to the fd.o CVS and SVN web interfaces?
More information about the xdg