Desktop Notifications Spec 0.3

[Geoff Youngs]

On Wed, 2004-09-22 at 14:45 -0700, Christian Hammond wrote:
[snip]
> I think there's either a misunderstanding in all of this, or
> something.

> Having clients send a sound filename is a bit pointless. Sure, do it
> via hints if you want it that badly, but the idea is that the server
> handles what types and such plays what sounds. It can do this
> *without* modifying the spec to include sounds. The server can play
> sounds based on the notification type and urgency, and then you have
> one place to turn them off.

> If we put sounds in the spec for the reason of "I want to turn off all
> my notification sounds at once!" then we may as well use the
> notification spec for all sound playback in all programs. That's going
> way overboard, and is not what the spec is for.

> So perhaps we can reach a compromise. If you want sound playback, the
> server should implement it, and it should not be in the spec. If you
> want your apps to play a custom sound, we'll set up a sound-file hint
> that the server can optionally support.

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.

If it is to be implemented by the server, should an alternative approach
to the notification types be considered?  As in some sort of hierachy?

e.g. 

presence.buddy-online
presence.buddy-invite

email.arrived
email.bounce

It would make it easier for a feature-rich server to implement sounds
explicitly suited/configured to the event in question, or for the
notification spec to support a possible future sound themes spec,
without needing explicit client support, while allowing sensible
fallbacks.

This would also open the way for a server to implement sound themes -
so, for example, instead of beeping, all mail notifications could lead
to an appropriate comment from Homer Simpson...

If this route was followed, it might be useful to have some database of
event-types, in a similar manner to, say, the shared-mime-database - so
that the server knows what it can expect (which could be helpful for
user configuration - enabling/ignoring events etc), but also whether the
event is a warning or simply informational.

XEmbed:
Please resist... the benefits of being able to have an all-singing-all-
dancing notification that a DVD has been inserted into the drive that
can play the credits sequence in the notification window itself simply
*doesn't* compare with the benefit of being able to look back at a
sensible, detailed log of past notifications (which I would expect a
decent server implementation to provide).

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.

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?

Just some thoughts,


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