Re: Proposed: systemtray-spec

On Sunday 08 August 2004 04:58, Mike Hearn wrote:
> On Sun, 2004-08-08 at 02:47 -0600, Aaron J. Seigo wrote:
> > i also wouldn't mind hearing from those who won't be there (e.g. any of
> > the GNOMEs on the list) what they'd like/need to see in a system tray
> > spec.
>
> I think the basic issue people have with it is that it's a system tray
> rather than how it's implemented :)

heh... yes, i'm not happy with how tightly coupled it is to a specific GUI 
representation. 

but there are lots of other issues, as well that range from how it complicates 
application logic around when to exit() their app (since the systray icon is 
"just another window") to "sanitizing" popup menus, to consistent behaviours 
for left/middle/right clicks, to being able to introspect and ask the app 
"how important is this systray icon? is it status only? does it provide some 
controls? is it currently active?" , to being able to properly handle 
painting issues such as applying a dynamic background to each icon (which, i 
accept, is not helped by current XFree86/x.org stat of the art), etc...

> This was the idea behind the recent notifications spec discussions on
> xdg-list: design a better way for actually notifying the user of things

yes, i think this is exactly the pragmatic approach the systray needs =)

from having dealt with and/or written code for managing all three bits of the 
systray (the client app, the systray GUI and the XEmbed voodoo) i've gathered 
what i hope is a fairly good idea of what is needed from a use case 
perspective:

Applications need to do one or more of the following:

	o Show the current status of the application
	o Allow easy access to the main window of the application
	o Allow basic control of the app (e.g. media players often use it to go 
forward or back at any point in time)
	o Provide a non-intrusive primary interface to the application (volume 
control, RandR apps, etc)

the Systray wants to:

	o have flexibility in how it shows the icons / etc (layout, painting, etc)
	o be able to categorize which icons should be shown right now  based on user 
preference[1]
	o be able to categorize which icons should be shown based on information 
supplied by the application[2]
	o be able to clearly communicate to the client apps when the user has 
requested their main window to be shown, the application to exit, etc without 
relying on the applications to provide what may be environment-specific 
support for these interations in their code
	o be able to manage the other bits of UI that come with systray apps, such as 
popup menus, so as to keep them consistent and standardized
	o not be hindered in its representation to the user based on what 
applications expect the systemtray to be.

> and then the other use case for the system tray (mini window icons that
> are present on all desktops?) can be sucked into EWMH,

i don't think it should be added to EWMH. we COULD but i think it's a poor 
fit. i'd prefer a bit more of a dynamic, though simple, IPC-based mechanism 
that provides clear separation betwen the systray and the client apps while 
not getting in the way of what apps use the system tray for in Real Life(tm).

> or we can simply
> define system tray policy as a window quick access tool.

is that what a taskbar is for? ;-)

[1] as a reference point, the WindowsXP systray allows some of these sorts of 
dynamic  behaviours, though not

[2] "Hey! I'm active and have something important to show the user! Show my 
systray representation now!"

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