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

[Aurélien Gâteau]

A. Walton wrote:
> 2009/6/12 Aurélien Gâteau <aurelien.gateau at canonical.com>:
>> 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.

Yes it's an inconsistency in the spec but since all implementations use
"icon_data", it's the de-facto standard.

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

Actually that's a question we should ask ourself: should we work at
defining a new DBus interface and deprecate the actual one or should we
try to evolve on the existing one?

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

This was initially suggested by Aaron Seigo, on the basis that nowadays
icons are always argb32, so the spec could be simplified. I do not
personally consider this change a must have, but it's true it's quite
hard to find an icon which is not argb32 nowadays.

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

So we would have this?

- icon:
 - app_icon

- image:
 - icon_data hint
 - image_path hint

At the moment the spec says app_icon is more important than icon_data.
This means an implementation which only shows one image, will never show
icon_data if app_icon is always set.
Instead the spec should say that icon_data/image_path are more important
than app_icon (and having both icon_data/image_path is indeed silly).

On one hand, your suggestion makes it possible to fit KDE use case in
the existing interface. On the other hand creating a new spec could be
the occasion to make deeper changes, for example fixing the markup problems.

Aurélien