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. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
