Icon names vs. emblems

[Matthias Clasen]

On Thu, 2008-06-19 at 20:17 -0400, Matthias Clasen wrote:
> 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

Any further comments ? 
I'd like to resolve this one way or the other...