Desktop Notifications Spec 0.3
l.lunak at suse.cz
Fri Sep 24 18:44:03 EEST 2004
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
> 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 ?
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/
More information about the xdg