Starting discussion on a new version of the notification spec

[A. Walton]

On Fri, Jun 12, 2009 at 4:51 PM, Brian J. Tarricone<bjt23 at cornell.edu> 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.
>
>> # 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.

And with this weigh in, that makes three major desktops (GNOME, KDE,
XFCE) in agreement on the issue. And that's all I'm saying about that.
*dawns asbestos armor*. ;)

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

I think we're trying to make sure we cover that better these days.
Alexander Sack provided a patch for libnotify that makes it a bit more
convenient for applications to ask for the capabilities, but I think
we should definitely put more work into this. There are at least three
server implementations beyond notification-daemon that I'm aware of,
"Naughty" in the Awesome WM, Canonical's, and KDE's, and it's likely
for servers to start growing features that aren't common to all, since
there's been little open discussion about new features in the spec.

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

Whichever way we come down on this, we should come down on it hard and
say that "this is the only way it's ever going to work, if you're not
doing it, _you're_ wrong". These encoding issues are the death of
everyone, and it's best we stomp them out entirely rather than letting
them drag on forever (like we did/have on the web, id3 tags in mp3s,
etc.)

I'm about 50/50 on the issue though. It seems to me that in this case
app writers are being lazy and not doing their part to ensure that
they're doing the right thing, but is that a function of us not
providing an easy way to do it (see my first paragraph), or is that an
artifact of developers just not caring? If it's the former, we should
do what we can to ease the pain (default encode all/make it super easy
to check/make the library do the checking for you/some other idea
here). If it's the latter, swift kick to their backside & bugs against
the app.

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

We should have a quick discussion about whether we should keep
auditory notifications a part of this spec at all, now that we have
another spec and software that competes with it. Does anyone else
implement sound hints? Does anyone else care to implement them as a
part of their notification software?

(Aside: For Notification-Daemon, it might be as simple for us to
forward "sound-name" audio-notifications through to libcanberra rather
than reimplementing the whole spec, which adds a dependency but gets
rid of a lot of applications depending on libcanberra.)

If we go the hint path, "sound-name" sounds better and less verbose,
but we'd definitely need to mention the sound theme spec somewhere,
with this being so new. "sound-themed" sounds really bizarre to me.

-A. Walton

>
> 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.
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>