Desktop Notifications Spec 0.3
m.hearn at signal.QinetiQ.com
Thu Sep 16 12:53:13 EEST 2004
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
The current reference implementation (on my laptop) has the following
- 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
- 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
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+
- 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
- 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
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:
> 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
- 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
- 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?
More information about the xdg