Notifications system discussion
l.lunak at suse.cz
Sat Jul 31 18:03:52 EEST 2004
Dne so 31. července 2004 14:27 Mike Hearn napsal(a):
> [context is: discussion about an as yet unproposed design for a desktop
> asynchronous event notification system which surfaced on the Gnome
> > 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.
After thinking about this again, I think your proposal and KNotify are
actually about the same, with only one (very) imporant difference - KNotify
puts the complexity to the server side, with client side being as simple as
just "event( event_type, event_type )", while you want to keep the server
simple and have the compexity in the client.
> 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.
But in a certain way your proposal actually contradicts this. With KNotify
client just does "event foo happended, with these details" and let's it up to
the server to notify the user in any way it sees fit. Your proposal includes
presentation details like sound files.
> 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.
I think that's insufficient, for KNotify at least. Let's assume this
hypothetical case: In a month from now, GNOME implements both client side
support for the spec, and implements GNotify daemon, which can notify about
events using passive popups, playing sounds or blinking a systray icon. KDE
implements the support in both KNotifyClient and KNotify daemon, gets also
support for feedback (so it will be a superset of GNotify in terms of
features except for the systray notification which it can't do).
Now, I run my KDE desktop, and run application KFoo, which can notify me
about the fact that foo happened. By default its events configuration file
says its foo event should be presented by a passive popup and a sound, but I
personally don't use sounds and hate passive popups, so I go in the KNotify
configuration, and in the section for KFoo I change presentation for event
foo to just blinking the taskbar (or turn it off, whatever).
Shortly after I realize GFoo can do about the same, but is much better than
KFoo for some reason, so I switch. However, now KNotify daemon will not
receive event name, but it will receive the description of the event instead
(sounds,and all the stuff that's listed in the spec). What can the KNotify
daemon do about that? It has no clue there is some GFoo with an event called
foo, and since your spec says the presentation is implementation detail, it's
up to KNotify to decide how to represent it. So it will probably show a
passive popup and play the sound, which, oops, I dislike. I don't care if
disabling passive popups would or would not be against GNOME usability ethos,
but I want to be to able to disable them in KDE. But as I said KNotify has no
clue about GFoo, so it won't even let me to change it. Even after adding the
suggested .desktop file name KNotify will know there is GFoo, but will not
know about the foo event. Bummer.
Let's ignore for now the fact that both KNotifyClient and KNotify daemon
would have to be schizophrenic in order to support for their KDE counterpart
and the spec. As the example above shows, the spec cannot be in this current
form extended to the level of KNotify features even by adding KDE-specific
> 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).
KNotify actually in practice doesn't have any presentation specification in
the API either. The most used way is just event( event_type, details ). There
are also functions dealing with the presentations, such as the custom events,
but I don't think those are actually used (I can't check now), as that'd kill
You probably think KNotify is some complicated monster, but it's actually no
rocket science. Current KNotify implementation is less than 1000 LOC. Even
after adding support for the feedback it probably won't get past this 1000
LOC (this is all without counting the configuration GUI). In fact, despite
the flexibility, it's rather simple stuff.
(In case you want to have a closer look, the client is in
kdelibs/kdecore/knotifyclient.*, daemon is in kdelibs/arts/knotify).
The KNotify "spec" is roughly like this: App wants to notify about some
event. It does DCOP call to DCOP client knotify, DCOP interface Notify, DCOP
function event(), where it includes event name ("newmail"), its appname
("kmail"), event details ("You have 2 new mails."), and technical details
(window id). It gets back id for this specific event. Aditionally it creates
a file describing its event types and puts in in a standard location. The
file looks like this
and if you ignore the localized entries, it's quite simple. It includes
description of the app, list of events and for every event a name for the
event, default presentation and presentation details (sound file,etc.).
Adding support for feedback means adding new data to the DCOP call and adding
That's about it (at least I hope - as I said, I'm no KNotify expert). Even
the events description file is the well-known .ini style file used e.g.
for .desktop files. Everything else can be considered implementation detail
of KNotify. I don't see how this is heavyweight or even too much work for the
clients. Creating a new client should be a piece of cake, a simple call and
few lines in a file. Creating MySimpleNotify server shouldn't be that hard
either. The only problem I can see extending the list of possible
presentations and handling the case when the server can't handle them all.
> 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.
Why exactly are those better done client-side, other than it being possibly
slightly simpler to do?
> 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
This must be a misunderstanding. KWin has an event called "minimized" (or so)
which has a default presentation in the form of playing a short sound, but
the actual minimalization is handled by KWin of course.
> 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.
Hmm. What's written above suggests another possiblity: KNotify gets a bit
extended and everybody could support only KNotify. Simpler (definitely at
least for KDE), more powerful, technology proven by years.
More information about the xdg