Desktop Notifications Spec 0.3

[Geoff Youngs]

On Thu, 2004-09-23 at 17:20 +0100, Mike Hearn wrote:
>  > Could I suggest that sound should be mentioned in the spec, as above?
> > But emphasising that the use of notification types by the server should
> > be the prefered way for the server to choose which sound, if any, should
> > be played.

> I'm not especially convinced sound as a hint makes any more sense than 
> sound as an optional argument to Notify - boils down to the same thing.

> I think nobody addressed the core issues with sound:

> - 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
 - There's no guarantee that the notification will be displayed on the
   same physical machine as the notification.

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

> - Why have to match notification server with preferred media framework,
>    instead of letting the apps decide?

 - It is more likely that the notification server will be an integrated
   part of the desktop environment than that the app will be.
 - If it doesn't behave as you wish, you've only got one server to fix
   instead of every app which uses the spec. 

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)

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

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

I might feel different if there was a freedesktop.org backed sound theme
specification which (a) existed and (b) was actually being used by GNOME
and KDE, but there isn't.  Even if one was written, it would be much
simpler for it to update a couple of servers than it would be to update
every app that notifies a user.

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.

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.
Equally it reduces the complexity of the preferences dialog for each
application, although that's probably of more interest to GNOMitEs than
KDErs.

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.  

I would *much* rather have a central point of control which affects
every application using the protocol, rather than using a variety of
differently designed application preferences dialogs when I wish to
change anything.

> > Screen origin:
> > Could you consider specifying that the "screen"/"x"/"y" hints can be
> > used to optionally highlight the origin of the notification?  If, for
> > example, there is a desktop applet for each attached drive, it would be
> > nice for a "Low disk space" warning to indicate by its positioning which
> > drive it refers to.  Although it probably has some potential for abuse,
> > for some events, relating them spatially to the iconic representation of
> > their origin could be useful.

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

Highlighting client-side might be better in some respects, but there
could be synchronisation issues and the visual effect of having the
notification display pointing at the icon in question would probably be
lost.

> > Desktop event logs:
> > The potential exists for the notification server to be used as a log of
> > "significant" desktop events - could there be an obligatory "nodisplay"
> > hint which indicates that the server may log, but may not display the
> > notification?

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

-- 
Geoff Youngs <g at intersect-uk.co.uk>
Horizon Technology