Great. Heres the spec in question if anyone wants to read and add anything. http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html
Also this interesting little article. http://www.xvsxp.com/interface/menuextrastray.php Toma On 05/03/2008, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Tue, 4 Mar 2008 23:59:44 +0900 Toma <[EMAIL PROTECTED]> babbled: > > > > Im trying to get some chatter about a new systray spec on the > > freedesktop.org mailing list. > > Since Im no programmer myself, I would like to try to just solidify > > some points that you all have and then put them all together and mail > > it into them. > > I figure the problem wont fix itself and some of you have some good > > ideas for it. > > Lets make some noise about this while KDE4 is fresh and see if any > > collaboration in that respect can happen. > > Toma > > > well i've made them before on the wm spec list, so here goes: > > 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 app (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 apps 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 app 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 app, 2. can be placed in more than 1 location if > desired, 3. can have a consistent look of any popup menus and controls and a > consistent set of interaction, 3. will match more with the usage of the tray > spec, 4. roll in other systems of abstracting this kind of "out of window > control" element from other UI systems (qtopia, hildon). > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
