Notifications system discussion

[Mike Hearn]

On Sat, 31 Jul 2004 17:03:52 +0200, Lubos Lunak wrote:
>  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.

Let's ignore sound files for now, as really that could be done client side
as well and I'm thinking it was not a good idea to put it in the spec. So
basically a notification consists of:

- summary
- optional body text
- optional image(s)
- action buttons

There are lots of different presentational styles that could be used for
this.

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

KNotify integration isn't necessarily a given - a separate server could
handle events generated by hypothetical spec-compliant clients using
whatever presentation the user prefers.

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

That's correct, so KNotify would use whatever the users default
presentation style is. Passive popups for me, some other mechanism for you.

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

If you dislike a particular presentational style, why not change it once
for all such incoming events rather than configure it on an app specific
and even event specific level?

I'd note that there's nothing preventing you from patching GFoo to
configure how it notifies you of events inside GFoo itself: in any case,
maybe this is better as the app itself can provide a far tighter and more
focused UI than a totally generic one can.

Nonetheless, I guess it would not be hard to have some kind of event ID
to identify particular types of event, so you have a (app id, event id)
pair that you can use to override the clients requests inside KNotify.

>  You probably think KNotify is some complicated monster, but it's
>  actually no
> rocket science. Current KNotify implementation is less than 1000 LOC.

How big the KDE implementation of KNotify doesn't really concern me to be
honest, what concerns me is:

a) How difficult it is to specify formally

b) How much effort it would take to implement such a spec inside other
desktops (not just gnome, I'm not a Gnome developer and neither is
Christian)

c) Keeping it very straightforward to understand for the developer

> Aditionally it creates a file describing its event types and puts in in
> a standard location. 

Yes, this is one problem I have with the KNotify approach, I don't
think having to install files in order to do a passive notification is a
good plan. It's yet more things to spec out (file formats, etc), means
that only "installed" apps can use the service as opposed to things like
shell scripts etc, and generally increases complexity.

Likewise, specifying presentation as part of the system makes it harder to
add interesting new presentational styles in future.

But basically if we were to add the app desktop name and allow apps to
specify event IDs, this would provide closer semantics to KNotify: the app
specifies the contents of the notification in the message and the server
can choose whatever notification it deems appropriate. In the KNotify case
it could let the user configure each event in each app specifically.
 
>  Why exactly are those better done client-side, other than it being
>  possibly slightly simpler to do?

Because it makes the spec simpler and gives extra flexibility as you are
not constrained by what is expressible in the protocol. For instance,
playing a sound: what formats are supported? what media frameworks are
used? what if you want it to repeat? All these questions disappear if the
app does what it wants directly, instead of asking something else to do it.

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

Yes of course, what I meant is that KNotify is clearly handling a lot of
different notification types: this spec is meant for coarse-grained
async (ie not triggered by the user) events that don't happen very often
and are supposed to grab the users attention when they do. So "you have
mail" or "you are running low on disk space" would qualify but "user
clicked a button" or "user minimized a window" would not.

thanks -mike