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

[A. Walton]

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
>
>