Hi I'm considering doing some work on the knotify-stuff for the kde frameworks. This involves the KNotification class and the KNotify daemon and related classes.
I started hacking a bit on it in Randa, but have ended up scratchig my work and starting over. http://pusling.com/blog/?p=200 Currently, it is a quite complex framework that is hard to debug for the users of knotify (the application developers). It seems a bit overengineered, at least compared to how many of the features that is normally used. the full knotify stack can notify users in I think at least 5 different ways: Popup Sound Run-a-command kttsd nothing But, for the developer that's not currently something to *directly* care for. The developer creates a KNotification object and sends it. This communicates over dbus to the knotify daemon. The knotify daemon looks up in the configurations what to do with it, and then does that. What does it do? For Popup, which is the all-dominating case, it sends out a org.freedesktop.Notifications conformant message (galago spec) For nothing, which is the next case, it does nothing for Sound, it plays something using phonon for kttsd it sends a dbus message to kttsd and for run-a-command, it runs the specified command. The user can of course change what a notification does. What I would like to do is the following: Create a handful of classes, either in a separate library or in a fitting library, basically giving a public api to skip over the configuration bits and knotify bits for the Popup case. There is code available for several platforms already in the knotify code. Make teh current knotify stack use the above code for popups and move it either to kde4support or to the high level platform integration bits. Depending on where it goes, I would like to also fold in the knotify daemon into the KNotification classes, as a daemon to - mostly rewrite dbus messages - seems a bit extreme[x]. Comments, requests for more details and questions are most welcome /Sune - developer for hire x) Yes. There is also two other uses. 1) to keep applications from having to link phonon for audionotifications and 2) to make sure that audio notifications will be played to the end when quitting a app
