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

[A. Walton]

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?

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

While this is true, it still adds code overhead to clients. In
implementations that always use argb32 image data, the hint is
currently filled with constants, and it's up to the server what to do
with the resulting image (e.g. re-encode it, display it as is, discard
it if it can't convert it). If we go with this change, it causes
implementations not using argb32 data to have to re-encode the image
before sending, which adds library bloat. And in the worst case, it
can even mean having to re-encode it again on the server to display
it.

It's not really broken, let's not 'fix' it.

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

With the above discussion, either both should be image_(data,path) or
icon_(data,path). Mixing the two is only confusing.

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

The markup problem is just another amendment once we come to a
consensus, though it does cause code changes (sometimes that happens).
Since there are fewer client implementations than server
implementations, it's not as much a problem at the moment. Fixing
broken application behavior may take longer, but hopefully communities
like Fedora's and Ubuntu's with their massive bug hunt days will find
and fix these quickly.

-A. Walton

>
> Aurélien
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg