Notifications system discussion
l.lunak at suse.cz
Tue Aug 10 16:32:06 EEST 2004
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).
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/
More information about the xdg