Notifications system discussion

[Lubos Lunak]

On Tuesday 10 of August 2004 09:48, Christian Hammond wrote:
> On Mon, Aug 09, 2004 at 10:40:34AM +0100, Mike Hearn wrote:
> > Olivier Goffart wrote:
> > > I originaly thought your proposed spec was a worse equivalent of
> > > KNotify. But it is not. We should see it as a better equivalent of
> > > KPassivePopup 
> > >
> > > KNotify handle events and notify them if needed.
> > > KPassivePopup just shows message.
> >
> > OK, I think this is a good perspective.

 This somehow brings up the question why do you need a spec at all just for 
passive popups. If you want just that, and want to do everything else in the 
client, why don't you do this in the client as well? Or the other way around: 
If you want to have passive popups in the server, why don't you do the rest 
in the server as well?

> > >Here is my proposal:
> > >Elaborate your specs and create the std "Notifier" which will only
> > > popups messages on the screens, and nothing more.
> > >
> > >-We will create a new deamon in KDE. i will call it now
> > >"KPassivePopupDeamon" (KPPD) but that name will probably change. which
> > >implemtents the spec and only the spec.
> > >
> > >-KNotify will stay as it and will just use KPPD if it wants to show
> > >messagebox. (If they run in kde. If they don't it will use the desktop

 messagebox -> passive popup I suppose

> > >notifier)
> > >
> > >-Nothing will change in KDE applications.  And others application
> > >(gtk,...) can call the notifier.
> >
> > This makes sense, and sounds like a good plan. What do others think?
> > Lubos? Christian?
>
> That looks great. I don't think there are any major issues with that.

 Hmm ... that looks a bit like legacy support for future technologies to 
me :-/ (sorry).

 Technically, I don't think KDE would need yet another daemon just for this. 
KNotify could handle that as well itself if needed (serve as the server for 
the spec if running in KDE or forward to the server if running outside of 
KDE). That'd of course need something like "There are non-KDE applications 
which can also notify you centrally about events, but unfortunately the 
configuration is limited. How would you like _all_ those events to be 
represented? <list of presentations>".

 It would be a possibility if we can't find any better solution. But I still 
hope we can find something better.

> 2) I'd also like applications to send along a notification detail ID.
>    The spec would define a number of standard notifications (which
>    we'll no doubt be adding to quickly), and non-standard ones would
>    use x-foo. This would allow the daemon to be more intelligent when
>    it comes to filtering. Like, if you get a email notification from
>    two apps within a very short time, only process one of them.
>
> If we have an application name and type ID, we could do per-type
> customization. The one thing, though, is that you'd only be able to
> customize notifications that have already been seen, but
> (theoretically, depending on the daemon, again) a global customization
> would suffice normally anyway. So you could set all mail notifications
> to just play a sound, and all buddy notifications from a specific IM
> client to appear in a bubble. Or whatever.

 Isn't this exactly what Mike doesn't like about KNotify? Because this looks 
like KNotify to me, maybe except for how the presentation defaults are 
specificed (knotify per-app config file vs whatever you mean).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/