systray specification...

[Bradley T Hughes]

Carsten Haitzler (The Rasterman) wrote:
> 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.

I like :)

However, even though the sizes of these icons tends to be small, the 
overhead of pushing/fetching the image data from the X server isn't 
something we should ignore (I'm thinking mostly about applets that 
animate their icons at regular intervals). Perhaps we could also have 
the option of simply specifying the name of an icon (which can be taken 
from the current icon theme)? Or a way of pushing all icons to the 
systray and a simply property/message to display a different image.

> 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. 

Like++

Since there are very few actions that the user tends to do with systray 
icons, the events would be very simple and few in number.

> 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.

Like++

Also, in cases where the applet wants to do more "advanced" things (like 
a mixer showing a volume slider), the application has to do it. We'll 
just have to provide a way of telling the systray what to do, e.g. 
telling the icon that button 3 should either send a message or open a 
named menu.

> Let the flames begin.

-- 
Bradley T. Hughes - bhughes at trolltech.com
Trolltech AS - Sandakervn. 116, P.O. Box 4332 Nydalen, 0402 Oslo, Norway