First of all, this is actually not really a reply to Aaron's mail. I started writing this even before Aaron's mail hit kde-core-devel, and it's basically my opinion on the system tray and a proposal what should be done with it. But it's related to this whole discussion, so let's keep it together. Also, since I started before this thread, I may be repeating some things, but I'd like to simply have all this as one mail instead of as scattered comments. So, here it goes: Let me start with the basic assumption: The systray is a broken concept. I mean like completely, in principle. Something that cannot be fixed by improving it technically. Systray is used for several different and rather unrelated things (minimalization, notification, status indication, applet-like functionality, fast access, whatever), and probably nobody can really say what systray exactly is. Aaron's "the system tray is a place for applications to embed little widgets" is actually a very good definition of what the systray is. Everybody uses it for everything. Dumping XEmbed for some alleged problems is not going to change anything on the fact that the concept itself will be still wrong. A random list of things that are wrong with the systray: - it mixes different concepts - there are "minimized" applications, there are status monitors, there are notifications, there are "applets" - it duplicates functionality from elsewhere - taskbar, normal panel applets - the close button mess complicates things for the user and for the developer (Aaron agrees :) http://www.kdedevelopers.org/node/view/251). The developer has to explicitly take care of the close button, and shouldn't preferably break session management. The user is confused (or upset) by the close button sometimes quiting the app, sometimes not. - some applications live in the taskbar, while other are in the systray - apps cannot be moved from the taskbar to the systray without their explicit support (I don't count unreliable hacks like ksystraycmd as something usable) - the placement of the systray icons cannot be affected - e.g. there's no way I can put kxkb on my top panel and kopete on the bottom one - We all know what happens when left-clicking or right-clicking on the taskbar (the configured actions ;) ), but this is not the case with systray - probably more, feel free to add Aaron's proposal clearly aims to fix some of these, but it might be simpler to dump the systray idea altogether and start from scratch (which doesn't exclude the possibility the result will resemble the original at least somewhat). The systray is currently used for the following things, at least the ones I can think of: 1) minimalization - e.g. kscd, amarok, ksirc and similar - The basic intent is apparently to save space from the taskbar. Every taskbar entry takes up some space, so instead of improving taskbar, let's move random candidates to the systray, which takes up smaller space on the panel. This is also the case that causes most of the problems above. - Suggested fix: Stop using the systray for this, and improve the taskbar. It shouldn't be a big deal to improve it so that certain taskbar entries can be shrunk only to the icon and moved to the right. Which in turn would even look a bit like the systray. Maybe it could be in fact even a separate applet, if people wanted to have it really separated on the panel (see? I said the result could be close to the original). But it still would be a taskbar, which would have a couple of advantages: - It would act like normal taskbar - no close button mess, no problem with what kind of clicking will do what with the associated window (the part of KSystemTray handling this is currently a big mess). - Aaron wouldn't have to bother with his spec for this. Taskbar entries already have things like application name, icon, descriptive text, even status is kind of there (the demand attention state). There are also actions like show/hide UI, quit. - It would work for all apps. - I'm not exactly sure what the UI for this should like exactly, I'm usually pretty lame when it comes to UI, but I currently imagine it as kwin having another titlebar button moving the window to this "tray area" of the taskbar, or perhaps it could be a switch, and normal minimize would move it there. The context menu on the taskbar entry would offer possibility to manipulate this as well. Additionally there's already the possibility to hide entries in the taskbar completely, although there probably should be also some way to revert this even if the window is not visible. - One more thing missing to be a good replacement for the current systray way of doing this is the context menu, e.g. the play/stop/next etc. entries for kscd/amarok. The idea is the application would simply associate the actions with its main window, and the taskbar would provide these actions in the popup. Since this is out-of-process, it's not possible to simply provide a QPopupMenu and give it to the taskbar (Aaron's proposal can't do this either as far as I can say). But the app can give the taskbar a list of the entries, and the taskbar can built the popup, and tell the app some entry was activated. No big deal with the usual text menu entries, if needed even some more weird menu entry types like sliders could be supported. This could be used for any app, even the ones with normal taskbar entries of course. Think e.g. right-clicking on the KMail taskbar entry and selecting 'Check mail' without switching to KMail before. 2) applet-like cases - e.g. kxkb, klipper - The reasons for making these systray icons instead of applets, as far as I can say, are: - It works also in GNOME. Which is why a spec for applets would be nice. - With high panels, it can take up less space (this is actually the reason why klipper is now schizophrenic - in systray there can be another systray icon above klipper, but not when it's an applet). This can be handled by better geometry handling of the applets. - Because being out-of-process also has some advantages, like when it comes to crashing. - Suggested fix: Stop using the systray for it, convert them to applets. Assuming Kicker's handling of the applet geometries improves a bit, one will be able to position applets much better in Kicker than systray icons. Another part is creating a spec that'd be shared with GNOME. The small problem here is Aaron would have to be treated for his allergy to the X character ;), like in the word XEmbed. But I fail to see how using e.g. Python scripts instead can be considered simpler. In fact I'd support Havoc's opinion that many of the alleged XEmbed problems are caused by incorrect usage of bugs (XEmbed is not exactly trivial after all). For example, while I haven't tried it for real, after consulting some X11 docs I don't a reason why fake transparency should be impossible with XEmbed. - One additional problem here is that the content of the applet window is completely controlled by the applet. This is definitely necessary for some applets, e.g. for the kmix applet (applet, not the systray kmix). But for many the functionality along the lines of 'show this pixmap' and 'show context menu', like in Aaron's proposal, is enough. I think this could be simply handled by subclassing KPixmapPanelApplet from KPanelApplet, which would solve Aaron's objections to applets. 3) Notification - I'd like to point out here that it's such a shame we've had KNotify since ages, offering so many possibilities for notifications and related features, and nobody has touched it since a long time ago. Pretty much everybody these days rolls their own notification stuff, in systray, using passive popup, whatever. If KNotify got some additional care, and everybody did just KNotifyClient::event("whatever"), we could simply have consistent notifications, consistent configuration for it, and new features for every app - for example, history of events, queueing of events, profiles (busy/silent/whatever). - Suggested fix: Ok, first of all, I don't intend to do anything about this. But if I happened to have a lot of spare time and felt an urge to do so, I'd try the following: KNotify gets features that prevent some apps from using it, for example feedback for events (so that e.g. Kopete can dump its own KNotify fork which has buttons with actions in notifications about events). It could get also the features I listed above. Apps would use KNotify only, and it would take care of it. I wouldn't really care if apps notified about events using passive popups, blinking the taskbar entry (which with the new taskbar "systray" would be basically like it's now), or by queueing systray icons (i.e. some apps notify about event by placing new icons in the systray, and clicking it opens new window with details about it - it would be preferably a separate kicker applet, a real notification area). - This would remove yet another use of the systray, and although as one option it could in fact result in a "systray" again, like 1), it would be a separate area in Kicker with a well specified purpose. 4) Daemons, quick access, whatever - This is stuff like alarmd (or whatever that systray icon KOrganizer brings all the time is called), the several systray icons from SUSE (susewatcher, suseplugger, profile switcher), and maybe even Klipper. - Probably the best description of this case is that these are the things that you usually don't want to see. I really don't care about alarmd as long as there's no alarm, just like I don't want to know about susewatcher as long as it has nothing to tell me (and when there's a new update available and it has something to tell me, it can then use notification). As I said, probably even Klipper belongs here - I actually don't want to see it, Ctrl+Alt+V and Ctrl+Alt+R does the job perfectly for me. The klipper icon itself doesn't provide any information, it's just taking up space, and providing quick access to the function for those who don't know how to activate it otherwise. - Suggested fix: Stop using the systray for this. This stuff should be invisible daemons, controlled by let's say their kcm modules. If there's need for some visual representation, there can be an associated simple kicker applet, which will using DCOP talk to the daemon. The same way there can be applets for the quick access, so that people not wanting such waste of space can still have the functionality, while those who want this simply add the applet. Oh, BTW, I forgot one problem, actually one of my favorites. It's a problem Klipper the systray app has, and Klipper the applet doesn't. If you disable Klipper from starting, do you know what the only and weird way of getting it back is? Ok, that's about it I guess. Since I hope I've covered all the cases, and suggested fixes for all cases include stopping using the systray, the conclusion of this proposal is that we can dump the old systray altogether. Moreover, given that 1) and 3) actually more or less have something like a systray as one possible result, we can call those two new things systray and notification area, and have people wanting that happy ;). It's just that this time it will be a much better systray and notification area. The nice thing about this proposal is that 1), which bothers me the most, requires only forking the taskbar applet or writing a new one, which I intend to do unless somebody persuades me this whole thing is a bad idea, so I can go for it and try at least 1) for real even if you don't like it. So, comments, flames, angry screams :) ? This is still no proper flamewar so far, I hope this helps you to try harder ;). -- Lubos Lunak KDE Developer