Notifications system discussion

[Olivier Goffart]

Le Samedi 7 Août 2004 18:18, Mike Hearn a écrit :

> - On audio playback: both WAV and OGG are container formats. They can
> contain very many codecs, so you have to start specifying stuff at the
> codec/bitstream level etc and it gets complicated fast. If you leave the
> client to deal with that, that complexity is avoided. If there are device
> conflicts, well this is a bug which should be fixed rather than hacked
> around in specifications :)

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.


> I think this discussion can be summarised at follows:
>
> - The proposed spec tries to avoid affecting the design of a desktop and
> keeps policy either undefined or in the client
>
> - KNotify keeps policy in the server and by design affects the way the
> desktop works (by requiring you to have a big central treeview/control
> panel type thing for configuring events).

no mather what is in the server and what is in the client library, KNotify put 
every code in the kdelibs (+deamon) and the application itself has nothing to 
do.

> So we seem to be at an impasse. I still have very big doubts about needing
> config files to trigger events (which only seems to be needed so you can
> configure events before they happen), and even about the UI implications
> of such centralised configuration.

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.

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.


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.


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 have no idea if a KNotify-style system would be accepted by eg, Gnome,
> as I'm not really involved with that project. From my understanding of
> their usability guidelines though, the answer would be "probably not" as
> they tend to frown upon very generic centralised UI like that. But perhaps
> I'm wrong.

We are still open in KDE to standardize it, that could be usefull to 
uniformize sounds themes.



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.