This is the period of the year when Plasma developers exits from under their rocks it seems, so there i am too, i wanted to blog about that since quite some time, but i am really too lazy lazy lazy to blog :p

As Aaron said, last months i’ve been quite busy with the implementation of the new systemtray specification. At Tokamak we gathered around a whiteboard and discussed what sucked about the current X systemtray, so… what if we could design it from scratch? well, let’s do it! this thinghie interested me so much that i jumped over it in a coding frenzy with i hope a sane amount of pauses to think about it and keep the design sane, scrapping stuff when the design direction seemed to take an ugly direction, process that is still ongoing, so all i will talk about here is still subject to changes, rennnames, replacements etc, nothing “production” still :p

Soooo, why we were really unhappy about the system tray we have now so much at the point to want to design a brand new thing? (and enlightenment people too, and this makes me happy since will permit us to have a really cross desktop design from day one)

There are several reasons, so let’s see one by one:

Painting, positioning and behaviour

Right now systemtray icons uses the Xembed protocol, that basically means they are windows owned by the client application process (very very roughly and pardon for the inaccuracy, kinda like the systray was their window manager). This means the painting of the icon is controlled exclusively by the client application, the systray itself has not much to say about that.

It means also, since systray icons have windows, i can’t have two system trays, (they would steal icons each other, since the window representing the icon s well, one) and, since plasma is canvas based, the implementation detail of whet xembed is will brutally come out as soon as you try to put another applet over the systray or try to rotate the applet or zoom the view where the applet is, as you can see here :p (yes, that could be kinda achieved with composite, but still a real hack)

OGG version

Moreover, nowdays our panel is a window that uses argb visuals, so it’s translucent when desktop effects are on (that means basically force 32 bits color depth on all windows representing icons). and that’s a thing that neither X or graphics drivers (or even qt, before 4.5) were ready for, the amount of bug reports about visual garbage into the system tray or icons that becomes invisible (nowdays still happens with intel cards and the problem doesn’t seem to be headed for a solution) were really many and quite discouraging.

Communication between system tray and icon

Or better, lack of thereof in the current spec. Now, the system tray limits itself to embed all the icons there are around (basically windows with _NET_SYSTEM_TRAY_S atom set) and after that, it knows exactly zero about them. Why it’s useful for those guys to talk to each other? Well, we all know the problem of cruft in the system tray, having 10-20 icons that steals half of the panel length or more is quite common, unfortunately…

Windows starting from XP made a timid attempt to solve the problem, by auto hiding system tray icons that din’t have activity for a given period of time (don’t know how since i don’t know how their protocol works) or alternatively manually hide icons you hate (ideally shouldn’t be necessary but the world is not, nice and fluffy with rocket launcher equipped ponies, misbehavers will always be here)

Now, in KDE (and any desktop that works on X by the way) we can hide icons but only manually, because the system tray has no idea what icons have activity, what are trying to notify something or things like that.

another interesting tought can come by looking at a typical crowded (and not even really crowded) system tray, icon by icon:

• The package manager screaming that i need super-important security updates: it’s a system service that needs user intervention every now and then, so it uses the system tray to notify that to the user.
• KMix: it’s an hardware control utility, it sits in the systray to give the user a quick way to control the volume without having to dig into the applications menu or systemsettings.
• Keyboard layout: it’s a system service, also there to give a shortcut rather than notify something
• Nepomuk: it’s a system service usually it’s not really useful to have it in the systray, but becomes neat as soon as it goes into the systray just when it’s indexing, to notify the user that is doing many disk operations, so giving to him a quick way to pause the indexing if he needs hard disk performance in that moment.
• Klipper: it’s a system service, that lets the user manage the clipboard, perhaps it would even make sense to have it in the panel out of the system tray..
• Kwallet: also a system service, access to the saved passwords, not a notifying function at all, it’s the typical icon that should be hidden until the user goes explicitly hunting for it.
• Konversation: it’s the status of a normal application, but it can be seen also as a communication thing, since those kind of applications tend to notify a lot they can be seen as a separate category (i.e, somebody is trying to talk to you, as in this icon)
• Amarok: it’s the status of an application, the icon itself says if amarok is paused or playing and the progress itself. quite used because once amarok plays it can be keeped as a background thing (i.e not in the taskbar and forget about it as long as it emits noise :))
• Skype: as konversation, it’s a communication thing, and also there the icon blinks when somebody tries to contact you
• Kopete: communication thing too

So what we have there: several categories:

1. Application status, like amarok in this case
2. System service: like nepomuk
3. Hardware status: like kmix or a battery or things like that

Application status icons in the future can be integrated into the taskbar for instance (did i heard somebody whispering dock? he will be punished :p), and even the other two categories could be separated in two different system trays, it gives more freedom to implement something that could exit from an usability study, with less fears of saying “ehmm, no sorry that can’t be done actually…”

The icons can have several statuses, we can think about 3:

1. passive: informational, but doesn’t require really user interaction, so it’s a thing that the system tray can decide to not show if not explicitly asked (in this example would be the package manager when doesn’t have updates, kwallet or nepomuk when idle).
2. active: the service is doing something or is a control that could be needed any time (nepomuk indicizing, package manager checking for updates, kmix that could always be handy there, battery indicator…)
3. Notifying: the icon requires an action from the user, for instance the package manager with new updates, or somebody that tries to contact you from kopete.

So we can now display the notifying ones in a different area of the systray, with a different background and we can hide the passive ones, and show them only when the user presses the unhide arrow.

so what we have now?

The main implementation skeleton is done, the specification it’s all based on dbus message passing, since it has to be a cross desktop thing. It’s divided in 3 parts: a kded service that keeps the list of the applications that wants to use the system tray (so the list won’t be lost due to a plasma restart) the protocol support in the systemtray applet (our systemtray could already support multiple protocols, since it was designed already with this possibility in mind since the refactor in KDE 4.2) and a client library in playground with a tiny test application used as a proof of concept, that can be seen in this video (yes, not a mind boggling spectacular thing, but still important), with also an interesting feature: when you stop the systemtray bookkeeping daemon, the icon magically falls back to the usual legacy system tray icon, so an application using this new protocol would still get systemtray icons when running
in a desktop environment that doesn’t support the new protocol.

OGG version

The client library and the dbus interface itself will pass trough a tough api review, so they can still change in a quite significant way (that’s why i didn’t go really in details in this post).

So don’t expect in KDE 4.3 all KDE applications to have been magically converted to this new protocol, but i hope all the plumbing will be there to permit application developers to start considering using this, and i’m really looking forward for other projects to cooperate to have a new unified shiny stuff 😀