On Fri, Sep 23, 2011 at 2:01 AM, Sune Vuorela <[email protected]> wrote: > On 2011-09-22, Sune Vuorela <[email protected]> wrote: >> 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
I agree that this is indeed a bit overengineered and complex. I have found myself a lot of times cursing it for requiring me to create a configuration file just to show a simple popup, plus not respecting any of the options on the KNotification object (as everything is re-read from the configuration file anyway). >> 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. > > Consider doing some classes for Phonon to do audio notifications for > those who needs that or alternatively get a cross desktop audio > notification dbus spec, just like the galago spec and get the workspaces > to implement it. (Issue here might be that Gnome has chosen that one > need to link libcanberra for audio notifications) > >> 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 I agree with parts of this plan, but not all of them. I think we need to study more the use cases. Let's consider a few examples. 1) Your IM client informs you of a new message. You probably want a popup, or a sound, or both, and possibly kttsd speaking the message (for people with disabilities), and of course you want all of this configurable. I think this is the best example use case of the current KNotify stack. The full capabilities of knotify should be available in this case, there is no point in having app authors reimplement this themselves. 2) Your music player informs you of the next song that is going to be played. You most likely want a popup here. Anything else would be annoying. Plus, there is no good reason for having this configurable from the knotify settings dialog, since it can just be a checkbox in the music player (which it already is in amarok for example). 3) Your voip software informs you of an incoming call. You definitely want a persistent popup with accept/reject buttons and you may also want a persistent ringing sound. Disabling the popup should not be allowed, or else users will not be able to handle the call, so the only thing that you can have configurable is the sound. 4) Your window manager wants to play sounds for window events like minimize, maximize, close, etc... There is absolutely no reason to allow the user configuring popups for these notifications, as well as anything else. Just sounds are enough. So, what I think that should happen is this: Create something in tier1 (or tier2 if needed) that allows people to just show popups, then something else to just play sound notifications, etc... These will be useful for non-KDE applications as well as for applications that want to handle configuration on their own (examples 2 and maybe 3 above). It is a pitty, for example, that at the moment there is no Qt library that can directly show popups using the galago spec and Qt software authors have to use gnome's libnotify or dbus directly for this purpose. Then, in the platform integration libraries or maybe tier2/3 solution libraries (not kde4support, as it is not something we are deprecating), place an equivalent of the current knotify stack, but perhaps simplify it a bit, as you said. The daemon is not necessarily needed (except for the sound perhaps), a lot of the options on the KNotification object are also not needed (they are read from the config file), QWidget dependency is also not needed, etc... In addition, I think that the knotify stack should be adjusted to target more specific use cases rather than being a generic framework that can do anything. It should allow to specify the kind of notification that this is meant to be (popup or sound or both or ...) and represent this in the configuration UI. So for example KWin and certain games that use knotify for sounds should be in a category with sounds and the users should not be allowed to configure popups for these notifications (as it makes no sense) and similarly for other cases. Try to study a bit what use cases we have in KDE, put them in groups and target each group separately. This will simplify things, both for developers and users. The current solution of having one system that can do everything and people using it for completely different use cases creates this feel of complexity that we have. Just my 2 cents... Regards, George
