systray specification...

Carsten Haitzler (The Rasterman) raster at rasterman.com
Thu Feb 2 09:56:29 EET 2006


Ok - since the systray "spec" is still 0.x and a draft and still not properly
implemented in all places... I think I'd like to bring it up for discussion. In
starting to implement it... I've run across some nasty issues. Let me bring up
an image as it says 1000 words... :)

http://www.rasterman.com/files/bad_tray.png

Notice different icons have differing bacgkrounds? They are all solid square
blocks? Well if you know the spec, you know why... so... anyway. Several issues
to bring up.

1. It's inconsistent in providing the message bubble contents with metadata so
the tray can display them any way it wants, but forcing the reparenting of
windows for display of the systray icon itself and interacting with it. One or
the other IMHO. not a mix. 2. Reparenting windows in this space leads to
inconsistent look and feel. The windows of these ststray icons are in practice
solid rectangular windows with either a solid color background inherited from
the widget set config, or they use copyfromparent for the bg and thus may also
look out of place if you have icons from differing widget sets, and rely on the
systray parent to use a bg pixmap or color to define the look.

I likely will get shot down here, but I think these 2 things above need fixing.
It's still a draft spec, so let's discuss possibly better ways.

I would suggest that instead of reparenting the window, the systray can have
the option of reading ARGB pixel data just like the NETWM_ICON property data.
The systray icon owner can modify this property any time and then the systray
can update the display accordinly. This allows for the systray to create a more
consistent look and feel, not sacrificing display ability for the application.
As for handling events the systray can send back events such as "selected"
"activated" "disabled" etc. when a user might click on a systray icon, via
client messages and the systray icon owner can respond bu modifying the icon
data or doing something. 

As for menu popups you see often when right-clickign a systray icon - why not
have the systray do this as it's doing bubbles too? At least the menus popping
up will be consistent with eachother on systray items. Menus could be described
via properties (limiting their scope of content to maybe icon + label +
optional radio/check item, separators and submenus, and results of user actions
with the menus sent back as client messages)? This would allow the desktop
environment to make all the systray metadata be consistent in terms of
function, look and versatility.

Let the flames begin.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)



More information about the xdg mailing list