Systray specification

[Toma]

Hello,
Let me start by saying that I am not a developer or a programmer. Just
a humble user and would like to see some discussion and development of
the systray. Im from the Enlightenment community and its common
knowledge in the community that the systray is not a very nice
standard and as such, is not implemented in E17. Ive had my gripes
with the systray since my good old Gnome days, then the same in my KDE
days, again in my Gnome revisited days and now, its really lacking in
terms of development. I believe its one of the areas of the free
desktop that could really shine with just a small amount of guidance.

Ive tried to follow the archives from where raster made a plea to
change the spec, but it seems to just disappear into the archives with
nothing actually resulting. Here are the points that raster has made
and I agree with them. In addition, I believe that all systrays should
have libnotification as it seems to be a common feature in gnome and
kde. This could replace the existing balloon messages section. Also
worth mentioning, is the systray Google Summer of Code idea for E17.
If this is taken on, a new systray with the said specs will be
available for testing.
http://wiki.enlightenment.org/index.php/SoC_Project_Ideas#Module:_Systray_.28Medium.29

Here are the points and issues.
1. systray "icon" windows are all implemented as solid windows. They are a hack
around using icon windows in good old ICCCM but no better functionally - just
much more obfuscated with all the selection mechanism stuff. As such they
suffer the problems of icon windows:

1.1 Can only have 1 copy of them on screen in 1 place. Doesn't allow a tray to
duplicate visual copies of them or functional ones.

1.2 They are windows - the implementations all assume that a tray will be in
the same toolkit as the application (gtk just creates little grey box
windows, kde/qt
assume copyfromparent is a good idea for the background - which is a bad
assumption). As such the spec discourages good implementation.

1.3 The spec should use the NETWM_ICON property to deliver an ARGB image to
display. The tray can scale, draw, composite or whatever it wants. It can no
create multiple copies. If the icon needs to change - a property change will do
the job. Doing more is probably abusing systray icons far beyond what they
should be used for.

1.4 As such systray icons have just become a way for applications to
avoid showing a
main window but stay running. They function often simply as a replacement for
iconification in icccm. Thus using the same mechanism is the better way to go.

2. As such icons want some form of interaction with users - do be able to
click on them to activate something or pop up a menu/dialog/popup of some sort.

2.1 We should implement a protocol via which an application can
advertise some form of
menu/popup structure to the systray so the systray can consistently implement
menus on all systray icons in 1 style and 1 unified look. This falls in line
with what is done in qtopia for the menu window (they use qcop to deliver this
data) and with hildon on the n770/800/810 and the separated menu window. It
would absorb this functionality as a unit on its own

2.2 In the case a systray cannot display what is needed being able to pass
events (mouse motion, enter, leave, press and release events) as well as
location of the tray icon relative to the root window.

This way -
1. The tray icons can be displayed with a consistent look irrespective
of the toolkit or tray application.
2. It can be placed in more than 1 location if desired.
3. It can have a consistent look of any popup menus and controls and a
consistent set of interaction
4. Will match more with the usage of the tray spec,
5. Roll in other systems of abstracting this kind of "out of window
control" element from other UI systems (qtopia, hildon)

(Basically a copy and paste from Raster)

Thanks for reading.
Toma