Hello + sound event architecture

[Kevin Krammer]

On Sunday 12 November 2006 18:11, Patryk Zawadzki wrote:

> Yes but there are some sounds (like "user clicks a menu activator") that
> should not generate a popup not a dialog. That's why I think a direct
> access DBUS namespace is required even if the notification daemon can
> handle the sound by itself in most cases basing on the notification
> type.

Sounds like a notification without visual representation to me.

> > 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.
>
> That's why I want to get a specification done.

That's why I think the sound theme specification is a good idea, but I still 
think that adding a separate sound-only notification service is not.

> > > > 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.
>
> The app could allow the user to override the default sound in its own
> interface. What if I want a specific icon for one of my IM buddies? Do
> you expect the icon theme specification to address that? :)

You got me confused now.
I say a user might have needs to play other sounds than those of a theme, you 
ask for an example which I provide, to which you reply the user will have to 
configure it outside the theme spec, which is exactly what I said, isn'it it?

> > > 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?
>
> That should be enough on the framework level. The rest is up to the
> application.

Just wanted to let you know that this level of customization is already 
available when using knotify :)
Any new solution will at least need this level of functionality otherwise the 
chance of it replacing knotify is quite small.
Any improvements are, however, quite likely to be accepted, so I suggest you 
have a very close look at the current notification implementations before 
suggesting a new one.

> > > 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 ;)
>
> See above :)

So I can assume we agree that sounds outside the theme spec need to be 
possible and be a simple file selection operation?

> As I already said, I'd like both the visual notification daemon and the
> soundnotification daemon get combined into a single app. But sometimes
> you just want a sound with no visual cues (like for button clicking
> sounds or when user decides that he does not want to see a popup when
> one of his IM buddies comes online).

This is just a configuration issue. Notifications do not require a visual 
representation, again at least not with knotify. I don't know any other 
notification implementation but I strongly doubt they require a visual part.

Since you also would like to have one single notification daemon, I do not 
understand why you want to artifically separate this two kinds of 
representation.
A separation means that there have to be two calls for one event if there is 
both an accustic and a visual effect.

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

[snip my previous answer]

> No, the notification daemon can delegate the sound event to the sound
> daemon (or handle it internally if it is a sound daemon itself) and let
> the latter decide if the sound should be played or not.

You got me confused again.
First you say that the application delegates the sound playing to the sound 
notifier and now it is the notification daemon?

> > Just calling a single notification API like now sound a lot easier to me.
>
> If you want both the visual popup and the sound, you should call only
> the notification daemon and let it take care of the sound event.

Which means the client or the client library has to decide on the 
notifications representation instead of letting the daemon decide.
Which implies that the client or client library have to know the current 
notification policies and be notified about changes to this policies.

IMHO this sounds a lot more complex than letting a single service to it, as it 
is implemented now.

What would be the most important advantage over centralized notification 
handling?

> > True. But in which use case would a client program want to play a
> > notification sound without doing a notification?
>
> See the first comment for a common usecase. Applications like Nautilus
> or GNOME Panel never use notification popups as the sounds are attached
> to things like "an application is launched" or "current path is
> changed".

Well, "an application is launched" or "current path is changed" still sound 
like notification events to me.
I get the impression you are assuming that a notification's representation is 
somehow required to have a visual part.

I find it quite unlikely that any of the currently used notification daemons 
would require this.

> > Or how would you synchronize the visual and accustical part if they are
> > separate method calls? In the worst case even to different daemons?
>
> If you need both, you let notification daemon handle both (or pass one
> to an external sound daemon if needed).

I am afraid I don't see the gain in bypassing the notification daemon for some 
subcategory of events.

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

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/2fdb4726/attachment.pgp