Notifications system discussion
ogoffart at tiscalinet.be
Sat Jul 31 20:06:09 EEST 2004
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
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
1) Less code duplication over the application, and applicaiton are shorter to
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.
More information about the xdg