Icon names vs. emblems

[Jakob Petsovits]

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
>
>   drive-harddisk+encrypted-locked
>
> which is currently not an allowed icon name (since the + is not allowed
> in icon-naming-spec-compliant icon names).
[snip]
> 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.)

Wishes,
  Jakob

P.S.: Whatever happened to the fd.o CVS and SVN web interfaces?