Notifications system discussion

[Lubos Lunak]

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
> desktop-devel-list]

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

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

 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 
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/konsole/eventsrc?rev=1.73&content-type=text/x-cvsweb-markup 
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 
a callback.

 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.

-- 
 Lubos Lunak
 KDE Developer