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'. _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
