Hello + sound event architecture

[Patryk Zawadzki]

Dnia 12-11-2006, nie o godzinie 16:54 +0100, Kevin Krammer napisał(a):
> On Sunday 12 November 2006 00:52, Patryk Zawadzki wrote:
> > This said, I'd like to ask a question (hope this was not discussed here
> > like two days ago as my internet connection is faulty and I am unable to
> > search through the mailing list archives).
> There have been several threads about notification handling.
> Almost everybody agrees on doing this with a session daemon, however things 
> like configuration (central vs. application specific) are usually debated 
> with very little progress.

I would expect slow progress to be a normal thing where standards are
discussed ;)

> > We do have a working specification for icon themes so why not just adapt
> > a similar specification for sound events?
> I'd say sound themes and notifications are orthogonal things. Sound is just 
> one presentation form of a notification.

This could be further expanded to cover all areas of notification but as
the galago-project provides us with a working notification-daemon for
desktop popups, I'd like to start with a generic sound event daemon and
then we can talk about a higher-level specification that internally uses
both of these.

> Depending on the actual notification architecture, users might have explicit 
> configuration for certain sounds, not just generic names.

Could you give an example?

My proposition would allow for more customization that is possible now.
User could replace certain soundby providing her own versions in
her .sounds directory. She can also opt to temporarily mute all sound
below a certain importance threshold for example to get a better movie
watching experience. Same could be offered by the notification daemon to
suppress the popups temporarily (and possibly offer a log to review
later).

> > The idea is to create a robust sound event handling system based on DBUS
> > that would allow an application to tell the daemon to "play
> > gaim-user-online with priority of notification," let the daemon handle
> > the event and let the app forget about it completely.
> So such a D-Bus service would then be used by the nofitication daemon(s) when 
> the event configuration indicates a representation including a sound?

Yes, it should be. But for a good start, letting applications themselves
delegate sound playback would be a huge step ahead.

> > To me such a daemon specification and a "sound theme" specification
> > would be a great start for even futher integration between various
> > desktop environments and between apps and their desktops as well.
> Well, I can see a definite value in a sound theme specification, however I'd 
> rather have the notifcation daemons or, in the event of a shared 
> implementation the notification daemon, do the sounds playing directly 
> instead of further delegating it.

You can combine both into a single daemon that just implements two DBUS
namespaces.

> I'd recommend concentrating on the sound theme specification. Just like the 
> icon theme spec it will already be useful without a shared 
> loading/caching/displaying/playing implementation.

This should be an easy thing to do given that the icon specification
works. I propose just rewording the icon spec to talk about sounds and
sound themes and removing the unneeded bits like "icon size"
subdirectories.

-- 
Patryk Zawadzki <patrys at pld-linux.org>
PLD Linux