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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
