Desktop Notifications Spec 0.3

[Mike Hearn]

> > - Why not do it client side (seeing as apps *already* play sounds async
> >   with app specific config ui)
> 
>  - Only some apps already play sounds.
>  - The client won't know when the notification is displayed

I guess the spec is a bit vague w.r.t this - the assumption is that it's 
displayed as soon as the server can process the Notify request. We 
should perhaps state that explicitly.

>  - There's no guarantee that the notification will be displayed on the
>    same physical machine as the notification.

I guess you meant client. Network transparent audio is a different 
matter that needs to be solved anyway, but it's not the place of this 
spec to do so.

> > - What formats are supported?
> 
>  - My personal preference would be to only permit sound to be played 
>    by the notification server, based on the configuration of the 
>    notification server for the event type, *not* the app's choice of
>    sound file.

Well, the spec doesn't need to be changed then as this is an 
implementation detail. The only problem would be if the client decided 
to do a custom sound as well, in which case they'd overlap. We could 
probably put something in the spec telling clients not to play sounds 
themselves though.

> Other core issues with sound include:
>  - How do I disable/re-enable all sounds related to notifications
>    quickly and easily, without muting the DVD I'm playing? 
>    (Unilateral configuration)

I think this is a matter for a different spec. It's more a generic issue 
... as I said, clients are free to do distracting things that aren't 
notifications and already do so today (think gaim popping up when 
somebody sends you a message).

>  - How do I ensure that gaim and gabber and kopete all make the same 
>    sound when a contact comes online? 
>    (Uniformity betweens applications)

I think that's again a matter for a different spec, sound theming or such.

>  - How do you synchronise the appearance of the notification with the 
>    playing of the sound?
 >
> (Noting that the spec doesn't guarantee that the notification will be
> displayed, nor does it guarantee even if it is displayed that it will
> happen immediately the application requests it)

Well, I think this should be fixed in the spec :)

> By including sound in the server, rather than the client, you also allow
> the server (or user) to have sounds for events where the application
> author(s) didn't feel need to play sounds, but which the user would like
> to hear sounds for.

I'd say that's a bug in the app, but perhaps the best way to solve this 
is simply to say that clients shouldn't play sounds for notifications 
themselves. That way, the server implementation is free to do what they 
want.

> Another reason is that of reducing application complexity: by
> abstracting the sound to the server you reduce the complexity of each
> application - notifying the user of an event simply involves invoking a
> D-BUS call, rather checking the user's sound preferences and possibly
> playing a sound.

I think this is probably better taken care of also by a sound theming spec.

> Equally it reduces the complexity of the preferences dialog for each
> application, although that's probably of more interest to GNOMitEs than
> KDErs.

If you assume sounds have to be configurable then it just moves that 
complexity somewhere else rather than reducing it.

> The other reason is that sound is offensive.  It's invasive in that it
> impacts on your senses even if you're not looking at the screen.  It can
> be distracting and anything which increases the complexity or the
> difficulty or reduces the accessibillity of a users' configuration of
> the noises their computer makes is a Bad Thing(TM), IMNSHO.  

All the more reason for a "don't disturb me" spec, I think.

> > Why not highlight the origin client side? What benefit does doing this 
> > in server provide? What about multiple screens? Z-Ordering?
> 
> Assuming (in an X evironment) the same display, then the screen number
> can be specified.  From there, it would be up to the server to ensure
> the notification appeared on the correct monitor (e.g. in a Xinerama
> setup).
> 
> The most common circumstance I would envision is a drive or battery icon
> in the system tray and (in the event that the implementation looks like
> tigert's mockups) the tag would be positioned just above the icon in
> question, although there are probably other ways in which it could be
> used.

Well, the thing with tigerts mockups is it's sort of hard to display 
multiple notifications at once like that, as they're all rooted at an 
icon somewhere on the panel (who says the user has a panel?).

The basic/default presentation style I was aiming for is an MSN 
Messenger poptarts style, but others are certainly possible. I don't 
think it makes sense to add features that are only useful for one very 
particular style of presentation though. It could be a hint I guess.

> > Yes, maybe. What are the use cases though?
> 
> Cases where an application might use a "standard" notification or it
> might use its own dialog, depending on the exact circumstances of the
> event.  The purpose would be to record it as a "desktop event" in the
> same way whether or not the notification server actually displayed it.
> 
> TTFN,

Hmm, well that widens the scope of the spec into a generic desktop 
events/logging/history type framework. Do we really want to go there?

Also, some notifications may not make sense if the actions are removed 
from them (ie they'd be out of context). Hmm.

thanks -mike