Notifications system discussion
m.hearn at signal.qinetiq.com
Mon Aug 9 12:40:34 EEST 2004
Olivier Goffart wrote:
> One of the main advantage of having the sound configuration centralized is for
> sound themes.
> And if we support the most common codecs in the specification, it's ok IMO.
> Anyway, i'm not going to force to uniform the sound themes if you don't want
Sound themes seem like a good idea, but I think it would make sense to
implement them like icon themes were implemented: a simple spec that
toolkits/APIs can look up and use, rather than doing it in a custom way
> 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.
> Actualy, unlike your specs says, There is no queue in KPassivePopups, they
> hide them eachother if there are several passives popups.
> And passive popup are not realy beautifull actualy.
Hmmm, OK, I didn't realise that :)
And I agree, with current X technology it's hard to make a pretty
passive popup. But with the upcoming support for X compositing, I think
we can make some truly beautiful and non-distracting passive popups or
even use alternative presentations like OS X style "bezels" or panel
slideovers. Well, there are many possibilities.
> 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
> -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?
> But since KNotify handle itself sounds, we need to add something in the specs
> to let the "notifier" know it may not play sound for this event..
I think that's OK. The current spec is already very loose about what
implementations can support (hence the caps querying request) - like it
says the content of the notification is the important thing, so most of
the information given in the Notify request may be ignored.
> We are still open in KDE to standardize it, that could be usefull to
> uniformize sounds themes.
OK. I suggest for now we leave sound themes, I think standardising them
is a separate proposal which should be done separately from this.
> Anyway, it would be nice if the same deamon used for passive popup
> notification (your specs) could also be used to play a sound, but with a
> different call. So we could use it also in knotify, and KDE application will
> not need to start artsd just for notifications if they are not runing in KDE.
That may be worth considering, although I thought the long term plan was
to not use aRts and let the underlying operating system deal with sample
I think Christian will be formally proposing the spec in the next few
days. I am glad we are making progress with this :)
More information about the xdg