On Thu, Jun 19, 2008 at 3:49 PM, Rodney Dawes <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg > _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
