Desktop Notifications Spec 0.3

[Lubos Lunak]

On Thursday 23 of September 2004 19:43, Geoff Youngs wrote:

> By including sound in the server, rather than the client, you also allow
> the server (or user) to have sounds for events where the application
> author(s) didn't feel need to play sounds, but which the user would like
> to hear sounds for.
>
> Another reason is that of reducing application complexity: by
> abstracting the sound to the server you reduce the complexity of each
> application - notifying the user of an event simply involves invoking a
> D-BUS call, rather checking the user's sound preferences and possibly
> playing a sound.
> Equally it reduces the complexity of the preferences dialog for each
> application, although that's probably of more interest to GNOMitEs than
> KDErs.
>
> The other reason is that sound is offensive.  It's invasive in that it
> impacts on your senses even if you're not looking at the screen.  It can
> be distracting and anything which increases the complexity or the
> difficulty or reduces the accessibillity of a users' configuration of
> the noises their computer makes is a Bad Thing(TM), IMNSHO.
>
> I would *much* rather have a central point of control which affects
> every application using the protocol, rather than using a variety of
> differently designed application preferences dialogs when I wish to
> change anything.

 [A lot of stuff that makes sense to me stripped. I'm glad somebody sees 
things similarly the way I do.]

 I personally think this notification spec proposal, with all this XEMBED 
stuff, client-side configuration and what not, is slowly turning into a 
complex monster. The especially amusing part is that it seems to show many of 
the (real or even just alleged) problems you had with KNotify.

 Now that this discussion got some attention here and it's not just 4 people 
discussing it, may I suggest an approach based on KNotify, as suggested in 
http://freedesktop.org/pipermail/xdg/2004-August/004307.html (scroll down to 
"KNotify spec v0.1:" is again considered? The only[*] _real_ problem you had 
with KNotify that I can remember of was the file listing the possible events, 
but if you're going to use notification types, that's basically the same. And 
since with KNotify everything is handled server-side, there are none of those 
synchronization, please-dear-apps-don't-annoy-the-user-now, sounds themes and 
similar problems. The KNotify way is just basically one IPC call, one simple 
file, and all the burden put on the server.

[*] Or will finally somebody extend the 'KNotify penalty points' list I did at 
the bottom of http://freedesktop.org/pipermail/xdg/2004-August/004402.html ?

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