Notifications system discussion

[Mike Hearn]

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 
> to.

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 
server-side.

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

> 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 
mixing?

I think Christian will be formally proposing the spec in the next few 
days. I am glad we are making progress with this :)

thanks -mike