Notifications system discussion

[Mike Hearn]

[context is: discussion about an as yet unproposed design for a desktop
asynchronous event notification system which surfaced on the Gnome
desktop-devel-list]

Here was the original "announcement" on desktop-devel-list:

> Mike Hearn and I have been drafting a spec for proposal to
> freedesktop.org that would provide a D-BUS service for such
> notifications. The spec is nearly ready for the peer review stage, and
> once people are generally satisfied, we will present it to fd.o. We
> also have a testcase library and daemon, which are a bit primitive
> still.
>
> The spec is available at:
>
> http://svn.freedesktop.org/galago/trunk/libnotify/SPECIFICATION
>
> Again, it's not finished quite yet. Comments, suggestions, and
> criticisms are welcome. We have received feedback from a few different
> projects, but we'd like more before we propose it.

It was not yet mentioned here as we wanted to gather feedback in private
first, but that plan went a bit awry, so .... here it is. Let's see what
people think. Remember it's unfinished! In particular I'm not sure having
sounds in the spec is a good plan, it could be done on the client side.

There is a reference implementation here:

http://freedesktop.org:8080/svn/galago/trunk/libnotify/
http://freedesktop.org:8080/svn/galago/trunk/notification-daemon/

Oliver Goffart raised some points on KNotify compatibility:

> The notification deamon of this draft is "just" used to display message
> (e.g. passive popups) and optionaly play a sound.
> 
> KNotify is a deamon which receive an event name and parse a config file
> to know what to do.

I raised the issue of KNotify compatibility on desktop-devel-list:

> Yes, KNotify is really a more generic system. I'm not convinced that's
> necessarily a good thing though - having configuration files and such
> for mostly passive notifications like "You've got mail" seems rather
> heavyweight to me. I can see what motivated that, but IMHO such things
> should definitely be optional. Config files for how an event should be
> presented should be an implementation detail of server policy, rathen
> than a formal requirement of the spec.

I haven't seen any arguments which changed my mind here. Actually
requiring config files to be able to send an event to the
notification server is too much work: a KDE implementation could easily
support this feature if it so wished, I doubt Gnome would be interested as
such levels of configurability go against their usability ethos. Other
desktops could do whatever they wished.

I think KNotify style configurability could be easily supported with a
small addition to the spec, namely an optional "desktop name", as defined
in the .desktop entry specification. When a notification includes this
name, the corresponding .desktop file is looked up according to the
algorithm given there, and the localised name could be read from that.

Likewise, any other configuration for events could then be linked to that
.desktop name.

On the other features requested:

> - A bitmask, or a string list, containing what action needs to be
> preformed (play a sound, show a passivepopup, a message box, blink the
> taskbar entry, raise the window, log to a file, execute a program, ....)

I don't think we want to specify presentation in the API. The spec avoids
this where possible, it simply suggests a toaster/poptart style UI as a
good candidate (and this is what the reference implementation does).

Likewise, logging, raising windows, blinking taskbar entries and so on are
all better done client-side rather than by the notification server itself.
The purpose of the server is to provide a central place to co-ordinate
multiple notifications so they do not conflict UI-wise, rather than as a
library of functionality.

Also, there's nothing that says this has to be a full replacement for
KNotify. You said minimizing a window goes via KNotify as well: this spec
is not designed for such fine grained events, as the use cases at the top
of the spec should make clear. KDE could easily support both KNotify and
the freedesktop spec, routing events as appropriate.

thanks -mike