Proposed: systemtray-spec

[Aaron J. Seigo]

On Sunday 08 August 2004 09:46, Havoc Pennington wrote:
> Here's an old crack at some opinions on this from Mark:
> http://mail.gnome.org/archives/usability/2003-March/msg00039.html

interesting. i think for the purpose of defining the spec this is not very 
useful since it dwells on defining system tray behaviour. the spec should, 
IMHO, define an _interface_. namely:

	1. by which the application can announce to the system tray / notification 
area / whatever you wish to call it that it has a set of information to 
present to the user in a compact form which may include a pixmap (either an 
icon by name or a custom pixmap), a text description, a textual status 
indicator, contents for a context menu, standardized states to allow the 
system tray to organize them, etc. 

	2. the system tray (and there may be more than one at a time, even!) can 
notify the application to take specific actions (show your main window, quit, 
perform action associated with menu entry X, etc)

this frees up the system tray (or whatever) to handle interaction and display. 
the aplications should have NO SAY in this whatsoever, otherwise we end up 
with environment specific behaviours coded into applications which may not be 
the same both over installations and over time and we end up severely 
constraining interesting behaviour that belong in the hands of the system 
tray such as selective hiding of icons, context menu generation, etc.

> I'm not aware of issues with XEMBED itself (other than "systray should
> be a notification system that doesn't hardcode displaying a widget") -
> afaik XEMBED works for displaying a widget, if that's what we wanted to
> do. But I agree that we don't.

that's half the issue. the other half is that it removes any and all control 
over the systray representation from the system tray itself, which is where 
it really should belong.

p.s. no need to CC, i'm on the list =)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43