Icon names vs. emblems

[Rodney Dawes]

On Tue, 2008-07-08 at 02:04 -0400, Matthias Clasen wrote:
> 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. 

This is a new API. It's just not in glib. It's something we must require
the artists to use in their themes, which means they need to do more
work assembling icons and emblems that could be done automatically
anyway. 

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

If this is for app developers to request an icon with an emblem from the
implementation, then I don't see the need for any new naming convention.
This would be an implementation issue, and doesn't need to be specified
in the Naming Spec. It could be added to the "looking up icons" section
in the Icon Theme Spec perhaps, as an additional complexity of look-up.

Your request is perhaps a bit ambiguous as to what you are requesting
exactly. It is not clear if you want themes to provide icons with file
names of icon+emblem.png for example, or if you want the implementation
to simply provide a new method of look-up for compositing icons and
emblems.

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

This is a clumsy API addition. It's a quick hack to get the API
functionality you want, without actually creating new methods in the
glib API.

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

Whether you add new methods in glib, or this new "string API" to request
an emblem on top of an icon, the app developers still have to change the
same code.

> > 3) My proposal allows artists to transparently produce custom versions
> >    of certain icon/emblem combinations; an 'emblem api' would likely
> >    preclude that

Artists already have the ability to create custom versions of certain
combinations. Adding an 'emblem API' or 'string API' to do what you want
would not change that. In fact, we already have several icons where we
effectively just combine an icon and an emblem. Take all the *-error
status icons for example. They are all just the normal icons, with the
dialog-error "emblem" drawn on top in the corner.

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

How do you intend to deal with the need for multiple emblems on an icon?
There are several instances where this does make sense, for example when
there is a symlink that points to an unreadable resource.

Also, if the goal is to add emblem functionality support to lower levels
of the stack, why don't we implement it as a proper API and just pull
the code out of nautilus that does it? This would give us a great start
on splitting up the concept of emblems and tags there, as well as help
push to unify the emblems concept across desktops. KDE (at least in 3.5,
I am not sure about 4.x) for example, uses "overlays" for certain files
where GNOME uses emblems. I am not sure what ROX or XFCE do, but
unifying the implementations here would be a great thing to do.

Sorry for the slow response. Finding time to deal with e-mail and open
source projects is extremely difficult at the moment.

-- Rodney