Icon names vs. emblems

[Matthias Clasen]

On Thu, 2008-06-19 at 18:03 -0400, A. Walton wrote:

> 
> The problem I see here is with the definition of emblems in the icon
> naming spec being too limited. There are a huge number of conceivable
> cases where having a representative concept overlaid with another
> makes sense. Take a look at some of the hundreds of icons included
> with Windows [2], or the special-cased icons for representing
> content-type over the document in Mac OS X [3] for an example of just
> how far you can go with this.

There is no 'definition' of emblems in the icon naming spec whatsoever.
The spec simply contains a fairly minimal list of possible emblems.

> Of course, the above is synthesized to fit this situation and I'm not
> really proposing system-lock as an icon, just using it as a go-to
> example. But there are many other conceivable cases. If you need to
> merge two ideas into one, such as "document" and "graph" (representing
> a graph or spreadsheet document), or "music" and "search" (searching
> for a music file).  If you wanted to represent a mounted disk image
> file with a "drive-mounted" emblem, or if you wanted to indicate that
> a file is being operated on with a "working" emblem. Maybe you want to
> represent a network workgroup or printer that's currently
> online/offline with an emblem (in the case that you have many of them
> in a view at once, like a printer manager or network manager). These
> examples wouldn't replace existing icons such as "network-offline",
> but would just be used to give applications some flexibility on how
> they want to represent it (you may not want to use the same icon that
> you would use in a task menu as you would in an icon view.)
> 
> So my proposed change for this would be to make it so that any icon
> can also be used as an emblem. However, conceivably many icons would
> look ugly if you attempted to composite them together arbitrarily, and
> we want to take that into account too. So the specification could be
> amended to add a special variant of an existing icon in the case that
> you want to use it as an emblem (e.g. "system-lock-emblem" in our
> hypothetical case). This icon would be a more easily composited
> version of the ancestor icon, and maybe telling theme developers to
> make it use proper alpha, shadows are bad, ensure that it's lower
> detail so that it is understandable even when rendered in small sizes
> and so on, general advice for emblems.
>
> Using current semantics, we could then fall-back to "system-lock" in
> the case the theme doesn't provide the special case. Or not fall-back
> at all, depending on if the implementation allows it, and based on the
> themers suggestion that the fall-back case is a good idea. This would
> add "EmblemFallback=[bool]" to the Icon Theme Specification as an
> optional case, defaulting to "false" if the key is not present as it
> may not work well with current icon themes and because this change
> would likely make themers want to take a look at their icons again.
> 
> This idea is slightly better in that it removes the implementation
> details that adding "+emblem-name" might otherwise infer (such as
> emblem order when rendered, complexity of having numerous emblems,
> etc). The example in GNOME's bugzilla [4] does the "profile" overlay,
> which really sells the concept that the two icons are merged into one
> concept. However, Nautilus needs to sell the concept that it's one
> item with some metadata attached, and other implementations may want
> to sell even more ideas, such as the state of use of an item. The
> specification shouldn't limit our abilities to do so by forcing us to
> do a lot of special-cased magic in themes.

Sorry, I cannot find any coherent proposal in this. Exactly _how_ do you
propose that applications should express the desire to use an icon with
an emblem ? My proposal has a very straightforward, no-new-api-required
solution for this problem, with minimal overhead. 

Multiple emblems and emblem ordering is totally an irrelevant
corner-case that should not define what mechanism we come up with.