Re: [E-devel] Systray - Ideas for a new spec
On Mon, 10 Mar 2008 15:25:45 +0100 lok [EMAIL PROTECTED] babbled: i agree with a lot of your points here. i've made them myself. the problem is people keep asking for systray support because apps go and USE/ABUSE it and they want that abuse supported. we can party support it in some ways so its functional but doesn't quite work until apps change their usage a bit. Hi, I took time to talk to this subject because I wanted to write my proof of concept before replying. In my opinion, a systray is a bad idea. For the last two weeks I kept asking myself, Why do people want a systray ? What exactly is a systray ? How can I provide it ?. For the first question I've directly asked to anybody I know was using trayer, or wanted a tray on E. The answers were about having a way to be notified, a quick way to show/hide some windows. A few were about using direct actions and each time with the same example, an audio player. And the last one that nobody say directly but somehow is always there, because they are simply used to it. For the second question, the easiest way to find out what exactly is a systray, it's to look at the source. A systray on windows is the only way to move an app outside the taskbar, the only way to keep visible an application running in the background but needs a GUI sometimes and was the only way to provide a pseudo gadget. Nowadays a huge amout of applications running on windows put something in the tray. Most of the time the systray have more applications than the taskbar, and 3/4 of them being hidden to take less place within the bar (so much for the monitoring). So what exactly is a systray ? I dunno, if it's a way to continuously notify why hide the icons and show a bubble ? If it's a way to lighten the taskbar why only the application as the power to choose ? And if it's a way to provide quick actions why do we still need this under our WMs were any one of them can use modules for years ? Well, here is the problem. A systray is a mess in it's basic design. Some half done thing wishing to compete with OS X dock. So write a spec, even good, about something doing a bit of (continuous ?) notification, a bit of quick action and a bit of docking isn't, in my opinion, the greatest thing to do. Of course it will works, but why redo half of the job instead of finishing it once and for all ? First let's have a _real_ fdo specification about notifications, galago's one was refused. It still miss some details, but I think it's a good base. And I believe it's something far more useful than just a common way to blink an icon somewhere in the screen (the urgent flag can already be used to do it). By pushing it a little I did the notification boxes : http://lok.eadrax.org/images/notification_box-3.png http://lok.eadrax.org/images/notification_box-4.png Which means than a good notification spec could cover all the aspect of notifications, popups and icons. Moreover I didn't implemented it but this spec handle actions, their purpose is to reply to an event. A docking specification doesn't seems necessary, we already have everything we need to dock an application like it would be in a tray. IIirk is the proof and IBox is also a solution. And finally for quick actions there is no common way possible. Depending on the purpose of the applications you will not wish to display it the same way. For an audio player, having a module giving you the possibility to play/pause/next/prev with a single click is better than openning a menu and choosing the good action in it. See http://www.kuliniewicz.org/music-applet/ for example. Whereas to quickly change a network like with network-manager you would rather have a popup with a list showing directly the name of the network, if it's protected and how good you catch it. All that using the same look than your WM. Redoing a module for each WM takes more work but end up nicer than reducing everything to a menu. Mixing iiirk and notification together would provide over 90% of what a tray does. Add to that IBar/IBox and you get something near OS X dock. Of course any other combination is possible. All this relying only on the .desktop spec, a notification one and the old NetWM's skip flags, breaking nothing and just requiring sometimes to install a notification plugin. So no I don't think we should change the tray spec, we should forget about it. Even if we do change it, even if we also manage to make the applications following the new one. All we will get is a bunch of icons stacked at their own will in a corner with the ability to open a menu. I would rather like to see a clean and complete notification spec accepted by FDO. Samuel 'lok' Mendes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
Re: [E-devel] Systray - Ideas for a new spec
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
Re: [E-devel] Systray - Ideas for a new spec
Hi, I took time to talk to this subject because I wanted to write my proof of concept before replying. In my opinion, a systray is a bad idea. For the last two weeks I kept asking myself, Why do people want a systray ? What exactly is a systray ? How can I provide it ?. For the first question I've directly asked to anybody I know was using trayer, or wanted a tray on E. The answers were about having a way to be notified, a quick way to show/hide some windows. A few were about using direct actions and each time with the same example, an audio player. And the last one that nobody say directly but somehow is always there, because they are simply used to it. For the second question, the easiest way to find out what exactly is a systray, it's to look at the source. A systray on windows is the only way to move an app outside the taskbar, the only way to keep visible an application running in the background but needs a GUI sometimes and was the only way to provide a pseudo gadget. Nowadays a huge amout of applications running on windows put something in the tray. Most of the time the systray have more applications than the taskbar, and 3/4 of them being hidden to take less place within the bar (so much for the monitoring). So what exactly is a systray ? I dunno, if it's a way to continuously notify why hide the icons and show a bubble ? If it's a way to lighten the taskbar why only the application as the power to choose ? And if it's a way to provide quick actions why do we still need this under our WMs were any one of them can use modules for years ? Well, here is the problem. A systray is a mess in it's basic design. Some half done thing wishing to compete with OS X dock. So write a spec, even good, about something doing a bit of (continuous ?) notification, a bit of quick action and a bit of docking isn't, in my opinion, the greatest thing to do. Of course it will works, but why redo half of the job instead of finishing it once and for all ? First let's have a _real_ fdo specification about notifications, galago's one was refused. It still miss some details, but I think it's a good base. And I believe it's something far more useful than just a common way to blink an icon somewhere in the screen (the urgent flag can already be used to do it). By pushing it a little I did the notification boxes : http://lok.eadrax.org/images/notification_box-3.png http://lok.eadrax.org/images/notification_box-4.png Which means than a good notification spec could cover all the aspect of notifications, popups and icons. Moreover I didn't implemented it but this spec handle actions, their purpose is to reply to an event. A docking specification doesn't seems necessary, we already have everything we need to dock an application like it would be in a tray. IIirk is the proof and IBox is also a solution. And finally for quick actions there is no common way possible. Depending on the purpose of the applications you will not wish to display it the same way. For an audio player, having a module giving you the possibility to play/pause/next/prev with a single click is better than openning a menu and choosing the good action in it. See http://www.kuliniewicz.org/music-applet/ for example. Whereas to quickly change a network like with network-manager you would rather have a popup with a list showing directly the name of the network, if it's protected and how good you catch it. All that using the same look than your WM. Redoing a module for each WM takes more work but end up nicer than reducing everything to a menu. Mixing iiirk and notification together would provide over 90% of what a tray does. Add to that IBar/IBox and you get something near OS X dock. Of course any other combination is possible. All this relying only on the .desktop spec, a notification one and the old NetWM's skip flags, breaking nothing and just requiring sometimes to install a notification plugin. So no I don't think we should change the tray spec, we should forget about it. Even if we do change it, even if we also manage to make the applications following the new one. All we will get is a bunch of icons stacked at their own will in a corner with the ability to open a menu. I would rather like to see a clean and complete notification spec accepted by FDO. Samuel 'lok' Mendes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Systray - Ideas for a new spec
Samuel (lok) wrote: Mixing iiirk and notification together would provide over 90% of what a tray does. Add to that IBar/IBox and you get something near OS X dock. Of course any other combination is possible. What's an iiirk? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Systray - Ideas for a new spec
iiirk is a new module thats in E cvs. Its quite nifty. Toma On 11/03/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: Samuel (lok) wrote: Mixing iiirk and notification together would provide over 90% of what a tray does. Add to that IBar/IBox and you get something near OS X dock. Of course any other combination is possible. What's an iiirk? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Systray - Ideas for a new spec
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]
Re: [E-devel] Systray - Ideas for a new spec
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
Re: [E-devel] Systray - Ideas for a new spec
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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Systray - Ideas for a new spec
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Systray - Ideas for a new spec
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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
