Notifications system discussion

[Olivier Goffart]

Le Samedi 31 Juillet 2004 14:27, Mike Hearn a écrit :

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

You think that because your idea of the notification deamon is not the same 
that KNotify.

From what i see, you just want a deamon to popup messages to the user. KNotify 
is not that  (but can do that)

KNotify handle all KDE events. That include for example KWin event when a 
window is maximized. KNotify will read the config file, and see if the user 
want to play a sound, and which one.  Of course, it is stupid to show a 
passive popup for such as events.


There are severals advantage of having "KNotify" handle itself the config 
file:
1) Less code duplication over the application, and applicaiton are shorter to 
code.
2) The Notify configuration UI is exactly the same for every application
3) We can apply sounds themes easily that may include all applicaiton (exactly 
like for icon themes)


Historicaly, KNotify was first only for sounds, and after, it has been 
completed to do much more things.

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

If we assume the configuration is hanlded client-side. The client has to tell 
the server somehow what it want to be performed.