Icon names vs. emblems

Thu Jun 19 15:03:54 PDT 2008

On Thu, Jun 19, 2008 at 3:49 PM, Rodney Dawes <dobey.pwns at gmail.com> wrote:
>
> On Tue, 2008-06-17 at 09:14 -0400, Matthias Clasen wrote:
>> On Tue, 2008-06-17 at 12:35 +0200, Jakob Petsovits wrote:
>> >
>> > As long as providing such a [base]+[emblem] icon is always optional for the
>> > icon theme, this might work out nicely. I think the language in your patch is
>> > not optimal yet, it should emphasize that this is mainly a feature for
>> > themers to provide tuned versions instead of the standard overlay mechanism.
>>
>> Sure, thats the intention. I can rework the language to make that
>> clearer.
>
> 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.

I'm more or less in agreement with this, see below.

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

David Zeuthen wrote an implementation of this in GNOME bug #538090
[1]. There are a number of reasons I'm not happy about it
specifically, but those are best left for discussions within GNOME,
and I'll comment on those there. (Though, the results are pretty nice
looking!)

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.

The obvious case I can think of is the "lock" icon. The specification
currently does not include any name for "lock" specifically, even
though it makes sense as both an icon, and an emblem. In the case of
an icon, you see the lock in many places, e.g. in Firefox to represent
a security zone, in dialogs to represent a secure action, and so
forth. However, as an emblem, the lock can mean that the represented
item is currently "locked" (no permission, resource contention,
encrypted file, etc)

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.

2 cents,
-A. Walton

[1]: http://bugzilla.gnome.org/show_bug.cgi?id=538090
[2]: http://wamp.corephp.co.uk/shots/s44.png (Look specifically where
I see "drive-removable" + ("floppy"/"cdrom"), "document" + "search",
etc.)
[2]: http://newmacuser.com/wp-content/uploads/2007/06/new-folder.png
(Look at "folder" + "media", etc)
[3]: http://bugzilla.gnome.org/attachment.cgi?id=112654 (The big SD
card with the lock composited over it)

> -- Rodney
>
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>