Icon names vs. emblems

[Matthias Clasen]

On Tue, 2008-06-17 at 12:35 +0200, Jakob Petsovits wrote:
> 
> 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.

Sure, thats the intention. I can rework the language to make that
clearer.

> 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.)

I'd leave that to the implementation, but I can't see how combining a
pre-composed folder+encrypted with a favorite emblem is going to work
practically, since you don't know which corner 'is already taken'.