I like the idea of using a hint more. As you said, this is a widely used spec at this point, and libnotify/notification-daemon are not the only implementations of this spec. I'd prefer we not break the world. I don't know about it being image_path though. One very common request has been to add the ability to send notifications to remote servers. While it hasn't been a priority, I don't want to rule it out altogether. If we replace our icon implementation with image_path, then that will never work in a remote case. We'd still have to send the image data. I'd rather image_path be a convenience of libnotify's API rather than being in the D-BUS API. Christian -- Christian Hammond - <a href="mailto:chipx86@chipx86.com">chipx86@chipx86.com</a> Review Board - <a href="http://www.review-board.org">http://www.review-board.org</a> VMware, Inc. - <a href="http://www.vmware.com">http://www.vmware.com</a> <div class="gmail_quote">2009/6/12 A. Walton <<a href="mailto:awalton@gnome.org">awalton@gnome.org</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2009/6/12 Aurélien Gâteau <<a href="mailto:aurelien.gateau@canonical.com">aurelien.gateau@canonical.com</a>>: <div class="im">> Hello again, > > In this mail I would like to address the first issue from the > notification spec I mentioned in my earlier mail: Ability to assign an > icon *and* an image to a notification. > > KDE notifications need to be able to show an icon and an image at the > same time. This is because KDE notifications can show an icon to the > left of the notification summary and an image to the left of the body > (see attached screenshot). > > 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. </div>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. <div class="im"> > > 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. </div>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. Servers can disregard them and clients can send whatever they want as hints. The way some of them are defined is a bit clunky right now, but it should be easier to go about adding a hint than it is to change the declaration of a well-defined, used-everywhere method. 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. The way that its defined right now, almost any image can be sent (basically it's a serialized version of GdkPixbuf, an arbitrary image container object). The advantage to sending almost any image is that clients don't have to drag in much in the way of image processing, whereas if we do specify the type, we'll have to convert any image that's not in the right format to what the server is expecting, which seems ugly to me. 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. That way server implementations can decide on what to show and when and where to show it. 2cents, etc. -A. Walton <div class="im"> > > 3. Define the following policy: > > """ > A notification can optionally have an image and/or an icon. > > An implementation must behave in one of these ways: > - Never show neither image nor icon. > - Show image if it is set, otherwise show icon. > - Show both image and icon. > """ > > What do you think about this? > > Aurélien > </div>> _______________________________________________ > xdg mailing list > <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/xdg" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a> > > _______________________________________________ xdg mailing list <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div>