On Friday 23 September 2011 14:24:54 Aaron J. Seigo wrote: [...] > now .. here's what i got from your email, please correct me if i'm wrong: > > the big question is this: should we have a central daemon, or not?
That is not how i understood Sune's email: I understood that he wanted to extract the (quite complex[1]) code that show popups away from knotify into another library. This library would replace the current KPassivePopup API for applications that just want a popup without using the full notification framework. Normal application would still use KNotification with all it's power, meaning no loss on features. So if I understand it right, I fully agree with Sune's plans. [1] It is complex because it supports many backend for different plaftorm (Freedesktop's spec with plasma or gnome, Growl on mac, KPassivePopup fallback, and whatnot.) > so probably a first question is: why do we currently have a daemon? The main motivations in favor of a deamon back in KDE 4.0 were: - Having a way to queue all the popups. This argument is void now that plasma is the actual "deamon" that does that. - Avoiding having every application linking to arts (or phonon, now), this may or may not still be a valid argument. > easy answer: it gives a central place for control and routing. > > unfortunately, it also means a lot of dbus calls and a fair amount of > complexity in the daemon itself. this means, in turn, high latency for > events, more processes running (not great for start up costs and resource > usage) > > so is there a way to remove the downsides while keeping the upsides? the > config dialog (which could use UI love, but that's a separate issue from the > work on the technology behind the scenes) can be retained as long as the > actions taken for events remain in config files. no daemon is needed for > that at all. what would be needed is a way to tell applications that > "notification settings have changed", and we have a way to do that already > using KGlobalSettings. perhaps that could be extended to cover the > notifications case. [...] Your analysis is correct. However, I beleive one of the main problem of the current stack is not the fact that it uses a deamon, but the fact that the configuration dialog is not user friendly, that make it almost impossible to use.
