[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KNotify-considerations for frameworks
From:       Olivier Goffart <ogoffart () kde ! org>
Date:       2011-09-25 11:38:10
Message-ID: 18058560.ZGKEhWLKdk () l09
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]