Icon names vs. emblems

[Matthias Clasen]

On Fri, 2008-07-11 at 14:19 -0400, Rodney Dawes wrote:

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

Fine, call it new api, if you insist. But I think it is a better way of
doing it than adding a new, say, GIconWithEmblem class in gio. For all
the reasons I've already outlined. 

And no, artists don't have to do anything different in my proposal.
Maybe that wasn't clear enough: foo+bar was meant purely as a naming
convention to express that you want the already existing foo icon with
the already existing emblem-bar emblem. There is no requirement that any
new foo+bar combined icon should be drawn. But using the naming
convention opens up the possibility that an icon designer _could_ ship
precomposed icon/emblem combinations with an icon theme, if he chooses
to do so.

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

True, and this is what I may end up doing. 

I still think that the icon naming spec would be a good place to mention
it. Since it already defines standard names for icons and emblems, a way
of naming icon/emblem combinations would be a good fit.

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

"Want" is a bit strong. 

But I do consider it a selling point of my proposal that it allows to
transparently replace icon/emblem combinations by a slicker, precomposed
version at the artists discretion, without any code changes. 

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

One mans clumsy hack is another mans elegant solution. 

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

Right. If we adopt my naming convention, we can stop the further
proliferation of such precomposed icons. Artists will have less work to
do.

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

I think file+symlink+unreadable would work ok. Leaving the details of
how to handle multiple emblems up to the renderer implementation.

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

The nautilus code is not necessarily the best for that. But how do you
envision a 'proper api' would look ?


Matthias