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

[Aaron J. Seigo]

On Saturday 13 June 2009, Brian J. Tarricone wrote:
> On 06/13/2009 02:56 PM, Aurélien Gâteau wrote:
> > A. Walton wrote:
> >> 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?
>
> Can we not achieve what we want with the current interface? 

for most of it, i think so, yes.

> Would be a
> shame to make all app authors redo their notifications code (though
> abstractions like libnotify might make that easy, or even transparent if
> done very carefully)

it's not all app authors, it's whoever is using libnotify. 

honestly, those using the dbus interface directly (assuming there are some) 
and expecting it to remain as is when it was an ad-hoc implementation by and 
for libnotify with no broader discussion is a little absurd and they deserve 
what they get.

> for uncertain gain.

the gain is a unified notifications system and making implementing and 
maintaining the various implementations easier and clearer, which translates 
to better chance of goodness for the users subjected to the various 
implementations of it.

(btw, versioning the dbus interfaces we standardize would also be a decent 
idea, imo)

> >> 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.
>
> I'd say might as well throw in the image format as well.  It's a tiny
> extra bit of information, and it's not a big burden to require it from
> the app author.

to take your earlier question and turn it on this statemetn: to what benefit, 
exactly? where are the real world use cases?

i really don't want to write, test and maintain image conversion code if i 
don't have to, and i thus far fail to see the benefit. it sounds a lot more 
like a theoretical issue rather than a practical one.

-- 
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/f62730a8/attachment.pgp