Notification spec issue: Ability to assign an icon *and* an image to a notification

[Christian Hammond]

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 - chipx86 at chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


2009/6/12 A. Walton <awalton at gnome.org>

> 2009/6/12 Aurélien Gâteau <aurelien.gateau at 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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xdg
> >
> >
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20090612/fe9adbc6/attachment.html