Proposed: systemtray-spec
Aaron J. Seigo
aseigo at kde.org
Sun Aug 8 21:23:58 EEST 2004
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
More information about the platform
mailing list