Icon names vs. emblems
mclasen at redhat.com
Mon Jul 7 23:04:47 PDT 2008
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
> 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
> 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...
More information about the xdg