[KDE4] KNotification

Lubos Lunak l.lunak at suse.cz
Mon Sep 19 16:24:13 BST 2005


On Saturday 17 of September 2005 18:12, Olivier Goffart wrote:
> Le Samedi 17 Septembre 2005 14:16, Gary Cramblitt a écrit :
> > On Friday 16 September 2005 07:46 pm, Olivier Goffart wrote:
> > > Le Samedi 17 Septembre 2005 01:11, Gary Cramblitt a écrit :
> > > > BTW, the freedesktop.org spec you reference already calls for a
> > > > notification "server", so KNotify doesn't really go away?
> > >
> > > Yes, but it will only handle passive popups.
> >
> > I'd like to know the reasons for wanting to get rid of the KNotify
> > daemon. I understand that you want to add widgets to notification dialogs
> > so that apps can receive feedback, but why couldn't this be done by
> > extending the existing API?  A dcop message from KNotify back to the app
> > comes to mind.
>
> There is in fact two things:
>  1)  the ability for the application to keep a track of the event (add
> action, and allow to say when it closes)
>  2)  use beatifull popup, even when running in Gnome.
>
>
> the #1 can be done with,  or without a daemon.  yes, it is possible to
> extand the dcop/dbus  API to allow that.
>
>
> It's because of the #2 anyway, that I want to change the daemon.
> The freedesktop specification (i don't know if it has already been accepted
> by freedesktop) say that there will be a daemon that will display popups.

 There's nothing like "accepted by freedesktop.org". You come, submit a 
proposal and if you're persistent enough (or just nobody really cares) it'll 
end up on the so-called standards page. What matters if it gets actually 
widely used. Trust me, I know this, as I'm the person who managed to have a 
freedesktop "standard" for a personal patch (it wasn't meant to be personal 
but I didn't manage to push it into Qt ... oh well). Of course this doesn't 
prevent some people from claiming something is holy just because it's listed 
on the so inappropriately named page.

 Specifically for this notification proposal (galago or whatever it's called 
exactly), if my memory serves me well, after their proposal half of the posts 
were silly mails about embedding pretty much anything including HTML into the 
popups and the second half were various objections (mine for example) which 
were generally handled "no, sorry, that's our spec and we want it to be this 
way".

 In short, if you want to implement it just because it's listed on 
freedesktop.org, you can as well write something better (which shouldn't be 
that difficult) and post it at freedesktop as a competting proposal.

> And the notification only cover popups.
>
> So every others powerfull features of knotify (run a command, log to a
> file, do a dcop call, blink taskbar, ....)  must be moved away.
>
> Yes, we could have two daemon, but that will be a bit too much i think.
> I think it is better to put that in the client library.

 In other words, you want to remove from KNotify what IMHO is it's greatest 
advantage. Not that it's been actually exploited, mind you, but the potential 
is there. Having a central point handling all notifications can mean things 
like:
- if it succeeds in becoming a standard, you can have e.g. Plasma 
notifications even for non-KDE applications, which you're not going to get 
with it handled client-side
- you can easily turn them all off or redirect them to a different 
presentation (manually, automatically by KPresenter, when the screensaver 
kicks in, whatever), or you can simply shut up a particular annoying app
- the central point can do things the clients cannot reasonably do, like make 
sure you don't get 10 passive popups at the same time but instead queue them, 
it should also make it easier to have new ways of handling notifications (I 
for example would just love it if instead of every app being in systray there 
could be an applet which would be just a queue of pending notifications)

 Indeed, having it out-of-process has some drawbacks too, like with the 
current way the systray works there's no way to change its icon from the 
outside, so the app has to do it (I guess this would mean the app would have 
to ask the daemon and it would tell the app back to notify using the 
systray). Or you won't have unlimited flexibility with out-of-process passive 
popups (or whatever will be the next really cool way of notifying), but how 
much do you reasonably need in a notification? If it's just a notification 
you're not going to have a complete HTML page in there.

 Given that KNotify's been pretty much unmaintained for so long and you seem 
to be the only person caring to work on it there's not that much room left 
for discussion but I wanted to raise my concerns nevertheless.

-- 
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/




More information about the kde-core-devel mailing list