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 - chip...@chipx86.com Review Board - http://www.review-board.org VMware, Inc. - http://www.vmware.com 2009/6/12 A. Walton <awal...@gnome.org> > 2009/6/12 Aurélien Gâteau <aurelien.gat...@canonical.com>: > > 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 > > xdg@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xdg > > > > > _______________________________________________ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg >
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
