A. Walton wrote: > 2009/6/12 Aurélien Gâteau <aurelien.gat...@canonical.com>: >> As of KDE 4.3, KDE uses its own DBus interface, which is quite similar >> to the org.freedesktop.Notifications except the "icon_data" hint is >> named "image_data" and the implementation shows both "app_icon" and >> "image_data" if they are both set. > > I think this is an inconsistency in the spec, since I seem to recall > one page referring to it as image_data and another as icon_data. Image > data is probably better, since it's more general.
Yes it's an inconsistency in the spec but since all implementations use "icon_data", it's the de-facto standard. >> Proposal: >> >> 1. Remove the "icon_data" hint >> >> 2. Add an "image" component to the notification, which would be >> represented as two parameters in the Notify() method: image_type and >> image_data. >> >> image_type: an int which can take the following values, indicating what >> image_data contains: >> 0: no icon >> 1: an icon name in a freedesktop.org-compliant icon theme >> 2: path to an existing image on disk >> 3: argb32 data represented as iiay (width, height, array of pixels) >> (This is a simplified version of the actual "icon_data" hint, which >> is a bit over-engineered.) >> >> image_data: a byte array whose content is interpreted according to the >> value of image_type. > > The problem with this is that it destroys the backward compatibility > of the spec. Hints are better for a change like this; they're Hints. Actually that's a question we should ask ourself: should we work at defining a new DBus interface and deprecate the actual one or should we try to evolve on the existing one? > Furthermore, width, height and array of pixels isn't enough to specify > an image. We'd need to say that all images passed over the bus via > this method have to be in a certain format. This was initially suggested by Aaron Seigo, on the basis that nowadays icons are always argb32, so the spec could be simplified. I do not personally consider this change a must have, but it's true it's quite hard to find an icon which is not argb32 nowadays. > So, rather than redefining the world, we could just add a new hint: > image_path (somewhere on disk). We leave the app_icon field in the > Notify() method alone since this is the application's icon, and should > be an icon-name as defined in the icon spec, and we say that it's > silly to have both image_path and image_data set and prefer one or the > other, probably image_data since we already have that in the spec, > though really that could be implementation defined too. > > If that's not enough, we can deprecate (not remove) the app_icon field > and add another hint for icon names as an array of strings which might > be a good idea anyways, since this way we could allow fallback icons > to be used in the case an icon theme is missing an icon. So we would have this? - icon: - app_icon - image: - icon_data hint - image_path hint At the moment the spec says app_icon is more important than icon_data. This means an implementation which only shows one image, will never show icon_data if app_icon is always set. Instead the spec should say that icon_data/image_path are more important than app_icon (and having both icon_data/image_path is indeed silly). On one hand, your suggestion makes it possible to fit KDE use case in the existing interface. On the other hand creating a new spec could be the occasion to make deeper changes, for example fixing the markup problems. Aurélien _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
