Icon names vs. emblems

[A. Walton]

On Thu, Jun 19, 2008 at 8:27 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> 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.
>

This is what I meant, thank you for clarifying. The spec only has a
very short list, whereas there are many cases beyond that where they
could be useful. Being flexible here would mean allowing
implementations to use any icons as emblems too.

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

Boiling it down would be:
-emblem for all icon names (other than emblem-, which would probably
be obsolete, but not necessarily)
if icon-name-emblem doesn't exists, look at icon theme
  if icon theme says icon-name is reasonable to use as an emblem
    use it;
  else
    maybe use it, depending on how important it is to the application.
default to not using it. note that using the icon at this point may
produce ugly results.
else
  use it

Both changes are small and smallish API changes may be required, but
could both be ignored by existing applications without much trouble.
Implementations would have to deal with how to carry around emblems
(in our case, GIcon hides the nastiness, in others you could serialize
the icons into a list, or use a list of strings, or do whatever else
you feel like).

Apologies if I wasn't clear earlier, I was just trying to come up with
the rationale for this and I somewhat rambled (I do that a lot,
apparently!)

-A. Walton