Starting discussion on a new version of the notification spec

[Brian J. Tarricone]

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.

> # 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 disagree with this.  Being able to interact with notifications is 
useful in the case where an app without a "normal" GUI (such as a wifi 
connection manager) wants input from the user but doesn't want to steal 
focus or block what's going on[1].  One might consider interactivity as 
an abuse of the concept of a "notification," but... who cares?  If it's 
useful, we should attempt to support it if feasible.  There's also the 
issue of supporting legacy notification bubbles from e.g. Win32 apps run 
via Wine, which often expect interactivity.

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.

2b.  Back to 'actions' again.  If an application wants to be conformant, 
  it should check for the 'actions' capability (which most probably 
don't do).  Even if they *do* check for this, the app author will have 
to write a decent amount of custom code to handle both cases (e.g. 
falling back to a normal dialog box if the server doesn't support 
actions).  There are two decent solutions to this: require 'actions' 
support, or handle the fallback case in libnotify (or in other 
desktop-specific client libraries).  I'd push for the former.

In general, I'd say support for features that only affect *presentation* 
(markup, image support, URL linking, etc.) is ok to be optional, but 
anything that affects *functionality* should be required.

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

All I can think of for now...

	-brian

[1] Yes, I know about non-focus-stealing windows... the problem with 
these is that they are poorly implemented across WMs: you can either use 
_NET_WM_USER_TIME, which all WMs may not support, or you can use the 
focus-on-map hint, which should be better supported.  Using either 
method (especially focus-on-map), you can't be sure that the new window 
is actually brought to the front such that the window is visible to the 
user (even if unfocused).  I suppose a solution to that might be 
_NET_WM_STATE_ABOVE -- not sure how suitable that is, or if it might be 
considered 'abuse' of the standard.