Hello + sound event architecture

[Aaron J. Seigo]

On Sunday 12 November 2006 12:30, Patryk Zawadzki wrote:
> Dnia 12-11-2006, nie o godzinie 20:08 +0100, Kevin Krammer napisał(a):
> > On Sunday 12 November 2006 18:11, Patryk Zawadzki wrote:
>
> Ok, I need more coffee to soundmore clear. I agree that the notification
> service should act as both visual and audible notification dispatcher.
> This should be no doubt a single service and it should take care of both
> sound and popups.
>
> I was just wondering if some applications could benefit from a pure
> sound API. 

of course they can. and this is a very different discussion that should be 
held in another thread or perhaps even elsewhere, but not wrapped in a 
discussion about notifications and sound themes.

sound APIs are not trivial, in part due to the way sound is used in some 
applications and in part due to the plethora of sound options that we have in 
the free software world. the people working on Phonon have worked hard on 
this particular issue and probably have a lot of insight here; it's also a 
discussion that ought to be had with the various media projects.

as far as "play a sound because something happened" this should simply be 
routed through the notification system. KISS. how the notification system 
plays that sound is an implementation detail, imho. why should the 
application care if it calls DBUS service X versus service Y to play a user 
feedback sound? in fact, i'd suggest that having multiple services would only 
be confusing ("Which do I use in this case: the sound service or the 
notification service? If I use the notification service, will it use the 
sound service?")

unified sound architectures are an interesting topic on their own though =)

> I'm not sure about knotify (being a GNOME user) but galago notification
> daemon has a freedesktop specification that allows both popups and
> sounds:

yes; we also provide logging to a file, notification via taskbar, command 
execution, printing to stdout and passive popups.

> > > See attachment for a draft.
> >
> > I'll leave the details to  the people with icon theme spec experience,
> > but shouldn't it be $XDG_DATA_HOME/sounds instead of $HOME/.sounds?
>
> It's based on the icon theme so all paths remained intact. At least they
> should (that might be my typo as well). Would love to see more comments
> or a guide how to make this draft a specification.

~/.icons is a historical thing with X, AFAIK. sounds have no such baggage that 
i know of, so let's not add it if we can avoid it. it should be, as Kevin 
notes, $XDG_DATA_HOME/sounds

some other comments:

 - can we name the default something obvious and which won't conflict with 
possible future themes? e.g. i can foresee a theme called "waltz" appearing 
and "waltz" doesn't say much to me. how about "default-sounds"?

 - is the $SOUND.sound file thing really necessary? would it be ok to put the 
information in these files in the main index.theme file in groups named after 
the file or some such? it just sounds like a lot of extra disk seeking to 
load a theme and more files to manage.

 - if this is to make its way to specification, let's not make the same 
mistake we made with the icon spec: let's start with a list of standard sound 
names and perhaps even some standard directory structure (e.g. apps/$APPNAME/ 
for app specific sounds?)

 - the notes on caching under "Implementation Notes" seem inappropriate for a 
specification. the mechanism described may not work on various systems today 
or in the future. how caching and other performance issues are handled is 
indeed an implementation detail and therefore belongs to the implementation 
of the specs

 - once closer to being ready, the specification should include a URL to an 
xdg-utils script that allows apps to install and retrieve sounds from the 
system. in fact, this script could even replace the pseudocode in the spec 
and be used as a reference implementation.

 - there is support for .wav files in the spec as a "legacy support" feature. 
is there any reason to do this? won't themes have to be created from scratch 
here and therefore during this process sounds can simply be encoded to ogg if 
needed?

 - in the lookup process, every subdirectory in the theme is searched. if two 
apps install a sound called "connected.ogg" but into 
$theme/apps/appone/connected.ogg and $theme/apps/apptwo/connected.ogg then 
the appone sound will always get played, no?  does it make more sense to 
enforce some basic directory structures within the themes and then beyond 
that require that applications specific the relative path, 
e.g. "my/odd/path/huzzah.ogg"?

 - this paragraph: "The lookup inside a theme is done in two phases. First all 
the directories are scanned for any sound that matches the name. If that 
fails we fall back on unthemed sounds. If we fail to find any sound at all it 
is up to the application to pick a good fallback, as the correct choice 
depends on the context." is confusing to me. which directories are scanned? 
in which order? do we look in each base dir completely, or in each base dir's 
$icontheme and then in each base dir's $parents and then in each base dir's 
$fallback? the example 'code' answers this, but it would be nice to 
disambiguate the text as well.

 - contexts: besides "actions" what sort of contexts do you foresee? is it 
useful to have contexts if there is only one? =)

 - there is no support for user customization of sounds that i can see? AFAIC 
this is bearable as the individual implementations can add this themselves 
though the downside is that this will be implementation specific and 
applications which don't share implementations will behave inconsistently. 
which probably isn't desired. =)

that's probably good for a start anyways =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20061113/0e393a78/attachment.pgp