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

[Aurélien Gâteau]

A. Walton wrote:
> 2009/6/13 Aurélien Gâteau <aurelien.gateau at canonical.com>:
>> 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.
> 
> Wasn't sure of this. It's not a huge problem either way, but we should
> pick one and stick with it (though honestly image_data still sounds
> better to me). Any problems changing KDE's implementation, or should
> we save this one for the next revision of the spec?

I think we all agree image_data is a better name, but if you change it,
you break compatibility. If I am not mistaken, adding hints does not
break compatibility, but removing/renaming them does.

>> 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.
> 
> Sure, but this basically means "for implementations only displaying
> either/or, you should display icon_data if available, since it's more
> important". Your implementation can choose to display both (or all
> three in the case of image path though this one starts to get really
> ridiculous, and should be discouraged in the spec; the point that it's
> 'possible' stands).

This again would break compatibility, since it reverses the priority of
icon_data vs app_icon.

It may be that I am too strict when it comes to being compatible with
the existing spec. I try to apply the same rules we use for BC (Binary
Compatibility), but it should not be the case, then I am personally fine
with these changes, which would make the spec usable by KDE IMO:

- Rename the icon_data hint to image_data

- Introduce the image_path hint, following the same convention as
app_icon (==either URI to image or icon name following fdo icon naming spec)

- State that an implementation which displays only one image must look
at the image fields in this order: image_data, image_path, app_icon

- State that an implementation which can display an app icon and an
image must look at the image fields in this order: image_data, image_path

Aurélien