Starting discussion on a new version of the notification spec
Brian J. Tarricone
bjt23 at cornell.edu
Fri Jun 12 13:51:12 PDT 2009
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
> # 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. 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
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
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...
 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.
More information about the xdg