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

[Aaron J. Seigo]

On Saturday 13 June 2009, 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?

changing the name would be fine.


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

only for clients that aren't dealing with argb32 image data.

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

so instead we make the server (of which there are apparently more 
implementations of than client support?) do the conversion? is that really any 
better?

as for library bloat, which libraries and what are they doing exactly?

the spec currently demands complexity for something that we have ~zero use 
for, and i don't know about you but i prefer not to write code just because i 
can ;)

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

agreed; app_icon, image_data, image_path seems to be the least confusing 
grouping.

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

but this is backwards; the application icon is not more important, as the 
image, if any is defined, is going to be more contextually significant to the 
notification.

a good example are IM notifications where the image would be the message 
sender's associated contact image. that's what we want shown, not the icon of 
the IM application.

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

imho, the spec should outline that if image_data is sent, that image_path is 
to be ignored even if defined.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090613/219bf05d/attachment-0001.pgp