Notifications system discussion
ogoffart at tiscalinet.be
Sun Aug 8 14:30:46 EEST 2004
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
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
> 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
> 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
-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.
More information about the xdg