Hello + sound event architecture

Stefan.Kost at nokia.com Stefan.Kost at nokia.com
Mon Nov 13 17:35:24 EET 2006


Hi,

for the gnome side the SoundMixerApplet (or even better the GSmartMix one) could offer the notification sound playing API. this could serve as the long wanted replacement for the play_sound() method from libgnome. If a user has no sound-card he wouldn't run the mixer applet and thus no play_sound service is available. The advantage of the GSmartMix integration is that it could handle the priorities and it can offer separate volume for notifications.

I see benefit in the separation from a notification daemon. The notification daemon will notify about things that happend (like new device found, or download ready). Not all this things have neccesarily sounds. The event sounds on the other hand do not neccesarily need to go through a notification daemon. Thus the notification daemon can use the play_sound dbus service to play a sound with a given priority.

Stefan

>-----Original Message-----
>From: xdg-bounces at lists.freedesktop.org 
>[mailto:xdg-bounces at lists.freedesktop.org] On Behalf Of ext 
>Patryk Zawadzki
>Sent: 12 November, 2006 21:30
>To: XDG - freedesktop.org's standards and specifications
>Subject: Re: Hello + sound event architecture
>
>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. Now that I think of it, a single 
>implementation should be enough.
>
>I'm not sure about knotify (being a GNOME user) but galago 
>notification daemon has a freedesktop specification that 
>allows both popups and
>sounds:
>
>http://galago-project.org/specs/notification/index.php
>
>> > 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.
>
>--
>Patryk Zawadzki <patrys at pld-linux.org>
>PLD Linux
>



More information about the xdg mailing list