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. > 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 the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
