Notification spec issue: Ability to assign an icon *and* an image to a notification
Aaron J. Seigo
aseigo at kde.org
Sat Jun 13 17:12:39 PDT 2009
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
> >> 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
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090613/f62730a8/attachment.pgp
More information about the xdg