Icon names vs. emblems

[Matthias Clasen]

On Thu, 2008-06-19 at 15:49 -0400, Rodney Dawes wrote:

> How is using a + any different from a - in this situation? Shouldn't we
> provide the icon, and the emblem (in their appropriate contexts), and
> the implementation then do what it needs with them? Why wouldn't the
> implementation just load the icon and the emblem, and overlay them in
> code? We already do this in nautilus for numerous file properties
> anyway.

The central point of my proposal is to give the implementation some hint
that the requested icon may be constructed from an icon plus emblems, in
a way that does not involve any new APIs or mechanisms, just a naming
convention. 

The + indicates what is the icon and what is the emblem. I don't think
you want to propose that implementations look for every possible suffix
as an emblem, or do you ? Ie if there is no weather-few-clouds-night
icons, do you want to look first for a night emblem, then for a
clouds-night emblem, then for a few-clouds-night emblem ? (of course,
none of these will exist). 

> Perhaps now would be a good time to implement some sort of "emblem"
> API in the icon theme implementation, and update the Icon Theme
> spec to clarify the "Emblems" context a bit. In the GIcon/GtkIconTheme
> case, it might be a good idea to add some sort of "list" of emblems
> for the icon. This way the emblem could be loaded and composited
> automatically in the right place.

There are several benefits of a naming convention vs an 'emblem api': 
1) A backend mechanism such as a GVFS mount can 'produce' an icon+emblem
   combination, without the need for a clumsy API addition to carry icon
   and emblem as separate pieces through all the layers from the vfs to
   the toolkit
2) Icon/emblem combinations can be used wherever we currently use an
   icon name, e.g. desktop files, GtkImage, GtkCellRendererPixbuf, etc,
   without the need to write tons of new APIs for each consumer of icon
   names
3) My proposal allows artists to transparently produce custom versions
   of certain icon/emblem combinations; an 'emblem api' would likely
   preclude that