Hello + sound event architecture

[Kevin Krammer]

On Sunday 12 November 2006 17:13, Patryk Zawadzki wrote:
> Dnia 12-11-2006, nie o godzinie 16:54 +0100, Kevin Krammer napisał(a):
> > On Sunday 12 November 2006 00:52, Patryk Zawadzki wrote:

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

Well, and knotify already supports popups, dialogs, sounds and ...

Of course, assuming that a sound handler would be available, knotify could 
delegate sound playing to it, however I think it is more likely that it just 
continue handling the sounds itself.
Given a sound theme specification it could play the same sounds solutions 
composed of galago and a separate sound playing daemon would use.

> > Depending on the actual notification architecture, users might have
> > explicit configuration for certain sounds, not just generic names.
>
> Could you give an example?

For example instead of having one "online" sound for all users in your IM's 
contact list, having specific sounds for certain users or groups of users.

> My proposition would allow for more customization that is possible now.

More customization than deciding if a sound should be played and which 
paricular one for each single notification?

> User could replace certain soundby providing her own versions in
> her .sounds directory.

IMHO sounds should be selectable from any path, requiring to copy a file into 
a certain location will make the usuability folks show up on your doorsteps, 
torches lit, rope ready and all that ;)

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

So, depending on the actual implementation, it would require two daemons to 
know about the current situation instead of just the notification daemon?
Wouldn't it be better to allow the notification daemon to temorarily alter the 
notification representation?

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

Hmm, sound like this would require the notification representation handling 
inside the client instead of inside the daemon since the application would 
need to know if it should play a sound and which one, and then call either 
both notification APIs or just the one for the visible part.

Just calling a single notification API like now sound a lot easier to me.

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

True. But in which use case would a client program want to play a notification 
sound without doing a notification?
Or how would you synchronize the visual and accustical part if they are 
separate method calls? In the worst case even to different daemons?

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

Sounds good to me.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- 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/20061112/42ce9014/attachment.pgp