Well, Ive put the old spec you made raster on the wiki (dug up from mailing list archives from 2006!) so everyone can see and discuss it further. Sure would be nice if you could look over it and change anything. Id like to attach it to the SoC idea about the systray, so that if it does get in, then we can produce a working example for the xdg folks to look at. Itll also need some applications that actually use it, so if anyone wants to include some systray code in anything, that too would be cool. Toma
On 10/03/2008, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Mon, 10 Mar 2008 13:33:21 +0900 Toma <[EMAIL PROTECTED]> babbled: > > > > 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 > > > it was the gnome camp last time that poo-pooed any changes to systray. seigo > was all for improving/fixing the spec. i sent changes to the spec to the > list a > full description of the ideas, but nothing happened. i always intended to > actually implement these changes. > > > > 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 > > > > > > -- > > ------------- 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
