Desktop Notifications Spec 0.3

[Mike Hearn]

Christian Hammond wrote:
> Hey everyone.
> 
> Mike Hearn and I are announcing version 0.3 of the desktop
> notifications spec today. We're hoping for some discussion on it, as
> some details will still need to be worked out. For the most part,
> though, we feel this is nearly ready for use. Any implementations
> using it now shouldn't have to change a whole lot by the time we have
> the final draft.

Yep. There are a couple of known issues with this version of the spec, 
based on experience gained while implementing it (which is why it's good 
to have a reference implementation :). I'll list them in a moment.

> We are not providing reference implementations at this time, as Mike
> is working on those but is for the most part without a network
> connection for the next couple of weeks.

To be more accurate I only have web and email access at work. Next 
weekend I'm visiting relatives so I have to wait to check in the work 
I've got.

The current reference implementation (on my laptop) has the following 
attributes:

- The server is written in a simplified form of C++, with multiple
   backends possible via inheritence. Right now there are only two, a
   super-simple console backend (just prints the notification really)
   and a GTK+ based backend that vaguely resembles the mockup made by
   tigert here:

http://nat.org/2004/september/gnome-notification-timeout-colorshade-anim.gif

- The client library is written as a glib/c library. It's quite simple
   though, Qt/KDE bindings to the protocol would take perhaps an hour to
   knock up :) It's done this way because these are the technologies that
   Christian and I happen to be familiar with. Neither of us are GNOME
   developers.

   It contains some unit tests, and a notify-send command which lets you
   send simple notifications from shell scripts. You *can* use dbus-send
   but the actual protocol isn't really designed to be used without some
   kind of thin wrapper.

- It supports most of the spec, including:

   - All the basics needed to actually display a notification
   - Static images
   - Actions, represented as hyperlinks a la the mockup in the GTK+
     backend
   - Basic layout
   - Simple markup courtesy of Pango

   Things left to implement are:

   - Animated images
   - Full markup support
   - Visual representation of urgency levels
   - Animations/slide ins/etc. Right now they just appear.
   - Positioning the notifications so they don't overlap the panels.
     KDE has some code for this in a generic NETWM class we may steal :)
   - Currently doesn't do anything with app name/icon. Not really
     essential

- Obviously it's not finished. I'm hoping to have at least animated
   images and urgency levels implemented before I head back to
   university. At that point it'll probably be up to other people to
   fill out the rest at least for a bit. That's OK though. Hacking on
   this is fun, I'm sure there will be volunteers :)

- It's designed with future, different presentational styles in mind.

   For instance you could subclass the GtkPopupNotifier class again
   and add code to use X compositing for extra eye candy, or you could
   have a QtPopupNotifier, or you could have a ticker-tape type
   backend that integrates into your desktop as a panel applet, or
   MacOS X style "bezels". These are coloured, translucent rounded
   rectangles which appear in the middle of the screen to grab your
   attention.

   No matter what you do, you can build on the reference implementation
   to reuse the DBUS connection code, [de]marshalling code, error
   handling code, layout code and so on.

> The specification is currently available at:
> 
> http://galago.sourceforge.net/notification-spec/
> 
> We are hoping that applications will start experimentally using the
> specification so that real-world tests can be done.

Right. At some point in the future, once it's been integrated with some 
real world apps experimentally and people are happy with the spec, the 
plan is to freeze the protocol and libnotify API then not break 
backwards compatibility from that point forward.

Here are some of the known issues with version 0.3 of the specification:

- Having expiry times given as seconds since the epoch allows for
   accurate timing (for countdowns and such) but suffers a nasty race
   condition. The time taken to page in the server from disk, construct
   the notification GUI, and perhaps load the given image from the icon
   theme is not zero, and actually on my laptop (600mhz with 128mb of
   ram!) this can sometimes take several seconds. If your notification
   is set to expire in several seconds .... yep, you guessed it. It won't
   appear.

- Actions should perhaps not be optional. If your program is relying
   on feedback from the notification it might cause some pain to be
   able to do without it.

   On the other hand, making a notification server a hard dependency of
   your application is probably a bad idea anyway. There's no guarantee
   the user will have it set up and running.

- The "backwards compatibility" section originally talked about KNotify.
   However, in recent discussions on this list it became clear that I
   had misunderstood the purpose and design of KNotify, and they weren't
   really similar systems at all.

   I think there is at least one KDE hacker interested in implementing
   this spec already, though I don't know their name. But, the plan would
   be to simply make it an additional part of the KNotify server. So,
   KDE apps would continue to use KNotify but KDE would still accept
   notifications compliant with this specification.

   That leaves the question of what the backwards compatibility section
   is doing there. Not sure :)

- Should markup be a required feature? If not, should it be stripped
   client side or server side? No strong feelings either way on this
   but currently neither the client lib nor server in the reference
   implementation do anything with markup.

- The "FOO or NIL" idiom used in the protocol may not be something
   DBUS and/or bindings are really designed for .... not sure.

- The spec doesn't really address error handling in any meaningful
   way. I've started putting error handling into the reference server,
   you can throw exceptions from most points and they'll be converted
   into DBUS error responses. But this should probably be a part of the
   spec rather than just a quirk of the ref impl.

   Examples of errors might be:

      * Image specified doesn't exist
      * Markup doesn't parse
      * Binary data provided for image isn't a recognised type
      * Protocol error

- The protocol doesn't currently let you specify the primary frame
   for animations (is this overkill? do people want animated
   images?) even though the spec talks about it.

- Do we *really* want more tags than just bold, italic, underline and
   hyperlink?

- If you embed an image directly into the notification it has to be
   a PNG file. Do we care enough about the resolution independent
   desktop to allow this to be an SVG file as well? You can already
   specify SVG files via the icon theme support, so does it make
   sense to let you stream it directly also?

- Do we need to specify UTF-8 encoding for strings or do we get this
   for free as part of using DBUS?

thanks -mike