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

[A. Walton]

On Sat, Jun 13, 2009 at 7:58 PM, Aaron J. Seigo<aseigo at kde.org> wrote:
> 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?

Servers have the choice of not implementing conversion, client's
wouldn't, which is the point here. In KDE's case, it's pretty simple:
send ARGB32, accept/display ARGB32. The extra fields just become
constants for clients. If another client send a differently formatted
image, the implementation could just drop it. However, ARGB32 isn't
the only format commonly in use (at least RGB24 is common for loading
JPEGs, especially coming from GDK).

Nobody's really expecting servers to go above and beyond the call of
duty here and support every format under the sun, but accepting the
simple ones makes sense to me. And anyways, isn't this one of those
RFC mottos: Be correct/specific in what you send, be tolerant in what
you receive?

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

I think we both mean the same thing, but the terminology is making it
confusing (which is why the hint /should/ be named image_data and not
icon_data, imho).

The app-icon will be the program's icon, and the image_data/icon_data
part will be a more specific icon, e.g. a message's icon. The daemon
should choose the image_data/icon_data (the chat sender's icon)
instead of the app-icon in the case that it can only display one of
the icons, but may display both if it can.

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

100% agree, just trying to make the point.

-A. Walton

>
> --
> 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
>
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg