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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
