Heres whats happened so far! http://lists.freedesktop.org/archives/xdg/2008-March/009303.html
Here are some of the summaries from people... "yeah, i'd really like to see this happen too. it requires someone to write the spec and start with implementations ... we've sort of all been staring at each other for a few years now waiting for someone to have the time and energy to do it. " -A Seigo (KDE Developer) "It doesn't make sense to try to write a new spec without having at least a proof-of-concept implementation. I hate the current systray too, and I have somewhere an unfinished attempt at a better implementation, but it's in the queue with many other things. Saying how the systray needs fixing is unfortunately not going to do that, somebody needs to find the time to make it happen." -L Lunak (KDE developer) No news from anyone in the Gnome camp yet, but I get the impression that everyone, including some people in the E camp that hate the notion of having a systray at all. Feel free to read the archive so far and/or join in the systray bashing on the mailing list there. Toma On 05/03/2008, Toma <[EMAIL PROTECTED]> wrote: > 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
