thoughts on the systray

[Lubos Lunak]

 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