Hello + sound event architecture

Tue Nov 21 22:17:34 EET 2006

Dnia 13-11-2006, pon o godzinie 10:34 -0700, Aaron J. Seigo napisał(a):
> ~/.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

I agree. This was a leftover from the icon theme spec.

> 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"?

Of course we can call it anything different :)

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

I think we can drop the information altogether - I can't really imagine
it being useful.

>  - 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?)

I was thinking about making the same thing applications do for icons,
calling the provided files application-soundname.ext, this way the
expected search order can be left undefined and the implementation can
use the most efficient way as the sound file names are unique inside a
theme.

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

Agreed, I will left that part out.

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

I will work on the scripting part as soon as we agree on the more
conceptual parts.

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

What about apps that need to support GNOME/KDE and Windows? There is no
easy way to play Vorbis files on MS Windows.

>  - 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"?

See above, I think we could benefit from sound naming guidelines - it's
easier to keep the structure flat and let the applications pick sane and
unique names. (In the above example, what if two apps decide to provide
"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.

I will rephrase that part to make it more clear.

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

First I thought this would add some common sense to the structure but
then I realized all the sounds are "actions" or "event" or whatever you
call it. Therefore this has no use :)

>  - 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. =)

I believe it's up to the application to present a user with a correct
interface and instead of calling a lookup procedure, pass its own sound
path to the notification daemon.

> that's probably good for a start anyways =)

Glad to hear that.

-- 
Patryk Zawadzki <patrys at pld-linux.org>
PLD Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: To jest =?UTF-8?Q?cz=C4=99=C5=9B=C4=87?= listu
	podpisana cyfrowo
Url : http://lists.freedesktop.org/archives/xdg/attachments/20061121/40d14484/attachment.pgp 