On Tue, 2008-07-08 at 02:04 -0400, Matthias Clasen wrote: > On Thu, 2008-06-19 at 20:17 -0400, Matthias Clasen wrote: > > On Thu, 2008-06-19 at 15:49 -0400, Rodney Dawes wrote: > > > > > 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. > > > > The central point of my proposal is to give the implementation some hint > > that the requested icon may be constructed from an icon plus emblems, in > > a way that does not involve any new APIs or mechanisms, just a naming > > convention.
This is a new API. It's just not in glib. It's something we must require the artists to use in their themes, which means they need to do more work assembling icons and emblems that could be done automatically anyway. > > The + indicates what is the icon and what is the emblem. I don't think > > you want to propose that implementations look for every possible suffix > > as an emblem, or do you ? Ie if there is no weather-few-clouds-night > > icons, do you want to look first for a night emblem, then for a > > clouds-night emblem, then for a few-clouds-night emblem ? (of course, > > none of these will exist). If this is for app developers to request an icon with an emblem from the implementation, then I don't see the need for any new naming convention. This would be an implementation issue, and doesn't need to be specified in the Naming Spec. It could be added to the "looking up icons" section in the Icon Theme Spec perhaps, as an additional complexity of look-up. Your request is perhaps a bit ambiguous as to what you are requesting exactly. It is not clear if you want themes to provide icons with file names of icon+emblem.png for example, or if you want the implementation to simply provide a new method of look-up for compositing icons and emblems. > > > 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. > > > > There are several benefits of a naming convention vs an 'emblem api': > > 1) A backend mechanism such as a GVFS mount can 'produce' an icon+emblem > > combination, without the need for a clumsy API addition to carry icon > > and emblem as separate pieces through all the layers from the vfs to > > the toolkit This is a clumsy API addition. It's a quick hack to get the API functionality you want, without actually creating new methods in the glib API. > > 2) Icon/emblem combinations can be used wherever we currently use an > > icon name, e.g. desktop files, GtkImage, GtkCellRendererPixbuf, etc, > > without the need to write tons of new APIs for each consumer of icon > > names Whether you add new methods in glib, or this new "string API" to request an emblem on top of an icon, the app developers still have to change the same code. > > 3) My proposal allows artists to transparently produce custom versions > > of certain icon/emblem combinations; an 'emblem api' would likely > > preclude that Artists already have the ability to create custom versions of certain combinations. Adding an 'emblem API' or 'string API' to do what you want would not change that. In fact, we already have several icons where we effectively just combine an icon and an emblem. Take all the *-error status icons for example. They are all just the normal icons, with the dialog-error "emblem" drawn on top in the corner. > Any further comments ? > I'd like to resolve this one way or the other... How do you intend to deal with the need for multiple emblems on an icon? There are several instances where this does make sense, for example when there is a symlink that points to an unreadable resource. Also, if the goal is to add emblem functionality support to lower levels of the stack, why don't we implement it as a proper API and just pull the code out of nautilus that does it? This would give us a great start on splitting up the concept of emblems and tags there, as well as help push to unify the emblems concept across desktops. KDE (at least in 3.5, I am not sure about 4.x) for example, uses "overlays" for certain files where GNOME uses emblems. I am not sure what ROX or XFCE do, but unifying the implementations here would be a great thing to do. Sorry for the slow response. Finding time to deal with e-mail and open source projects is extremely difficult at the moment. -- Rodney _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
