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

[Brian J. Tarricone]

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?  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) for uncertain gain.

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

> 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 can be worked around in client libraries, probably, 
by querying for capabilities and stripping markup from input if it's 
provided.  The daemon should treat all input as markup (with properly 
escaped characters) if it advertises the 'markup' capability, and as 
straight text to display if not.

What other problems exist that can't be fixed within the confines of the 
current spec?

	-b