Desktop Notifications Spec 0.3

[Christian Hammond]

On Thu, Sep 23, 2004 at 04:28:03PM +0100, Geoff Youngs 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.

Yeah, we can do that.

> 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

I like this. Much better categorization.

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

Homer Simpson should be considered in every spec.

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

Nod.

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

Yeah, I have to agree here. We have other tools (or can make new ones)
to stuff other things in. We don't need to stuff stuff (I love
English) in a notification. That would hurt logging, and limit things
for console apps, graphical apps using a framebuffer but not X, etc.

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

Hmm, I think this is possible, although maybe this is a better reason
for including a window ID or something as a hint?

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

It seems to me that we have /var/log/* files for things like that.
These are designed to be notifications, not a logging service. I can't
see a case for this where a log file wouldn't just be a better
solution in general?

Christian
 
-- 
Christian Hammond         <>  The Galago Project
chipx86 at gnupdate.org      <>  http://galago.sourceforge.net/
   There's always free cheese in a mousetrap.
-------------- 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/20040923/bfc11813/attachment.pgp