Features Download

From: Lennart Poettering <mzxqr <at> 0pointer.de>
Subject: Re: Sharing an Event Sound Infrastructure in GNOME and KDE
Newsgroups: gmane.comp.kde.devel.general
Date: Thursday 12th June 2008 16:11:36 UTC (over 10 years ago)
On Tue, 10.06.08 20:21, Lennart Poettering ([email protected]) wrote:

> Heya K-lovers!
> I'd like to draw your attention to the event sound work for free
> desktops I just announced on my blog:
> http://0pointer.de/blog/projects/sixfold-announcement.html

Ok, let's wrap up this discussion, so that I can end my endeavours in
KDE land, and go back to my native GNOME lands. So, here's my (biased,
of course) summary of the mails in this thread.

1) KDE people are apparently happy with the sound theming/naming specs
   (or at least the idea thereof). 

   Further discussions about this topic should please happen on the
   XDG mailing lists.

2) Most KDE people don't really think that libcanberra is a good idea
   but more a "major step backwards", they prefer to stick with
   knotify for everything. I tried to point out that this
   will eventually turn out as insufficient, unless it is really
   beefed up in which case it won't be a notification API anymore, but
   more a notification plus audio effects API. KDE people see no
   problem in relaying major amounts of input events to knotify. In KDE
there is
   no toolkit integration for sounds right now, and as far as I
   understood if there is something planned, it would also use
   knotify. Most KDE people are not too concerned about having
   stuff like event sounds for a11y, sound effects (spatial event
   sounds!) or cacheing in their sound event system.

   OTOH a minority seems to agree that deeper aureal feedback for
   toolkit actions would be good, and also things that libcanberra
   is not as evil as their collegues think.

   Those interested in libcanberra know where to find me, if they want
   to work on Qt/KDE integration of libcanberra. But the work in that
   direction in Qt/KDE has to come from ... you!

3) The KDE people think that generating 
   window-close/window-new/maximize/... events from the toolkit is a
   bad idea. The only somewhat valid reason for that opinion they came
   up with is support for apps written in older, legacy toolkits. I
   don't really agree with this however, since older toolkits won't
   be able to provide sound effects for their input events anyway. So
   if we move the source for a few more sound events from the wm to
   the app, it will be just a few more among a number of others that
   no sounds are generated for in those legacy apps. Also, I claim 
   that thinking about non-Gtk, non-Qt apps is a waste of time anyway.

   Alternatively, KDE people want to export all information that
   is necessary to generate those window events properly in all their
   detail to the WM. I tried to point out why this is not really easy 
   to do and probably not worth it: it would be a lot of stuff, a lot 
   of new XDG specs to be written, also how should the reason why a 
   window was closed be exported to X as prop? (i.e. dialog-ok vs. 
   dialog-cancel). Also, what to do about the race between a menu
   popped down and another one popped up and knowing that this was
   tiggered by only a single action, and thus only a single sound
   should be played?

4) And the fun things: some KDE people have broken shift keys on the
   keyboards, and others insist that knotify ain't like GNOME's
   notification-daemon on stereoids. And it seems to be OK to post
   HTML emails on kde-devel. ;-)

Any real flaws in this summary, except that is heavily biased from my
POV? If not, then let's and this dicussion here, and I can remove my
subscription from kde-devel soon.


Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
   GnuPG 0x1A015CC4
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub
to unsubscribe <<
CD: 74ms