Hello + sound event architecture
patrys at pld-linux.org
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
> - 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
> - 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
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
> - 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: To jest =?UTF-8?Q?cz=C4=99=C5=9B=C4=87?= listu
Url : http://lists.freedesktop.org/archives/xdg/attachments/20061121/40d14484/attachment.pgp
More information about the xdg