Desktop Notifications Spec 0.3
chipx86 at gnupdate.org
Thu Sep 23 19:16:42 EEST 2004
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?
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
> 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.
> 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
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 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
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040923/bfc11813/attachment.pgp
More information about the xdg