Re: GNOME 2.10 module proposal: libnotify and notification-daemon

[Mike Hearn <mike navi cx>]

On Mon, 08 Nov 2004 21:00:12 +0100, Lubos Lunak wrote:
>  Yes. If my memory serves me well, it was roughly like this:
>  -> We have already KNotify, why don't you simply use that as basis and add if 
> something is needed [*]
>  <-  Sorry, KNotify is too different, and we find it too complicated [**]
>  -> How about at least this KNotify feature?
>  <- Sorry, that'd require first changing the proposal to work like KNotify

The thread in question is on xdg-list.

> [*] The proposal has some things which KNotify doesn't have, like the list of 
> possible actions, but I don't see why a problem adding them (hey, knotify is 
> pretty old technology).
> [**] Which is nonsense, if you ask me, 'wc -l' on the daemon code gives <900 
> lines and <700 lines on the library class. It'd perhaps double after adding 
> actions and such things.

The complication wasn't that of the code. For comparison, n-d is
currently ~1400 lines of c++ including whitespace, mostly due to not using
any bindings for ease of install/portabilities sake and our
whitespace-heavy coding style. 

The thing we felt was too complex was the need to pre-configure all
possible notifications. We felt having a simple "fire and forget" system
outweighed the advantages of telling the system about possible
notifications beforehand. It'd be a lot simpler for things like shell
scripts, kernel integration etc to use the service if no setup was
required.

The main reason it seemed that KNotify did this
was so you could configure individual notifications from individual apps
to do different things before they'd happened, as given the
app-name/app-icon properties in the protocol you could configure the style
of each notification once they'd actually happened and therefore been seen
by the notification server. So the only thing you lose is being able to
install an app and then configure every notification before it happens.

Non-notification specific policy can be configured in the daemon
implementation just like any other piece of desktop policy.

The app-name/icon things complicate the spec somewhat (and there's no
guarantee the sender is actually an app or has an icon so they're
optional) but it lets you achieve 95% of the KNotify effect.

This has all been covered in the xdg-list thread by the way, I thought I
might as well re-iterate it here so nobody concluded we objected to
KNotify on code size grounds.

thanks -mike