Starting discussion on a new version of the notification spec

[Aurélien Gâteau]

Brian J. Tarricone wrote:
> Aurélien Gâteau wrote:
> 
>> We want to work with upstream developers to find
>> an agreement so that applications can display notifications in a
>> consistent way, regardless of which toolkit has been used.
> 
> Sounds great!  FYI, I work on Xfce, and I'm the author/maintainer of 
> xfce4-notifyd.

Oh I didn't know about this implementation! (didn't do my homework well
enough it seems). Will give it a try.

>> # Other issues/suggestions?
> 
> 1.  Passive vs. active notifications.  I recall that notify-osd 
> unilaterally decided that the 'actions' bit of the spec was Bad[tm] and 
> that notifications should be entirely passive and not accept input.

I would rather not start a discussion on this subject: it has been
debated to death and people won't change their mind.

> 2.  Minimum features.  I'd say that some more features should be 
> *required* in the notification daemon than currently are.  As the Ubuntu 
> spec notes, many (all?) all apps in the wild seem to assume support for 
> anything notification-daemon supports, and not check the daemon's 
> capabilities as they should.  Some features cause trouble if they don't 
> exist:
> 
> 2a.  If the notification daemon doesn't support body-markup, then, in 
> theory, it should display body text in raw, unescaped form.  Obviously, 
> then, clients should only send plain text in that case, but most 
> probably don't (since they don't check for the body-markup cap).  I'd 
> suggest requiring that all body text be html- and entity-escaped.  The 
> daemon can decide whether it wants to show the formatted text or strip 
> the markup.

This is one of the point I listed "Problems with markup in notifications".

> 3.  The Ubuntu spec adds a 'sound-themed' hint, while we already have 
> 'sound-file'.  I'd suggest just overloading 'sound-file' to take either 
> a sound theme name or a sound file.  Implementations that only support a 
> full path will simply fail to play it; no big deal.  With 'overloading', 
> implementations don't have to handle Yet Another Hint.  Downside: apps 
> wishing to provide a sound theme name plus a fallback sound file path 
> won't be able to.  Is that a big deal?  (There's also the cosmetic 
> question as to what "sound-themed" logically means.  It should be 
> something like "sound-name" or "themed-sound-name".)

This is only present on the wiki page, notify-osd does not support sound
at all at the moment. I believe this is just a mistake.

Aurélien