True. I suppose in this case, we wouldn't necessarily use D-BUS anyway. 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">On Fri, Jun 12, 2009 at 2:26 PM, A. Walton <<a href="mailto:awalton@gnome.org">awalton@gnome.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On Fri, Jun 12, 2009 at 4:23 PM, Christian Hammond<<a href="mailto:chipx86@chipx86.com">chipx86@chipx86.com</a>> wrote: > 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. > </div>The way I think about it is that if we have a daemon that forwards over the network at some point, that it's probably more convenient for it to handle the image_file/image_path hint and translate it into image_data hint before sending the packet. This is probably how sound_file would have to work as well (if an implementation bothered to forward those). Both cases reduce bus traffic at the price of a bit of server complexity. -A. Walton <div><div></div><div class="h5"> > Christian > > -- > Christian Hammond - <a href="mailto:chipx86@chipx86.com">chipx86@chipx86.com</a> > Review Board - <a href="http://www.review-board.org" target="_blank">http://www.review-board.org</a> > VMware, Inc. - <a href="http://www.vmware.com" target="_blank">http://www.vmware.com</a> > > > 2009/6/12 A. Walton <<a href="mailto:awalton@gnome.org">awalton@gnome.org</a>> >> >> 2009/6/12 Aurélien Gâteau <<a href="mailto:aurelien.gateau@canonical.com">aurelien.gateau@canonical.com</a>>: >> > 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. >> >> 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. >> >> > >> > 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. >> 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 >> >> > >> > 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 >> > >> > _______________________________________________ >> > 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> > > > _______________________________________________ > 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> > > </div></div></blockquote></div>