Starting discussion on a new version of the notification spec
aurelien.gateau at canonical.com
Sat Jun 13 14:18:09 PDT 2009
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
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
> 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.
More information about the xdg