Tag Archives: systemtray

Again on the unsystemtray


I see last entry sparkled a bit of discussion, so a recap is needed on what are the goals of our redesign for the ground up of the systemtray, form the low level protocol to the visualization.

The systemtray was almost always intended as a “notification area” (this always was its official name) and most implementation until now failed at it. The Windows systray failed because every commercial application wanted to put its “brand” on it, the X11 systemtray failed even in a worse way, because there was zero communication between the applications and the systemtray and there was no semantics at all in the items.

So the visual representation had to be pretty limited, it could just put there all the icons that registered themselves and nothing else.

The “notification” nature was failed by the fact that is was just an huge disorganized list of everything and the kitchen sink, so the option to manually hide some of them got in. This was again a failing of the notification concept, a manually hidden notification item can’t notify anything right?

But hiding icons would not be a bad thing if you can ensure that the ones that are actually notifying something are indeed visible, so -manually- hide/show icons can’t work.

That’s one of the reasons we wrote a whole new protocol for those items, called StatusNotifier (and -not- sytemTraySomething), this is already being implemented from third parties, for instance the next Ubuntu release will make extensive use of it. In the new protocol, an item is in a passive state unless it decides it really needs to be active (i.e. has some useful status information, like the battery charge) or is notifying something really important (like, the battery is running out).

Any information that doesn’t belong to the latter two cases, simply should not be there, as well doesn’t belong there its usage as a tiny taskbar, that will go completely away in the future (probably to go on another widget or in the taskbar itsef).

As a result, the visualization (that is what’s is improperly called systemtray) now can use much more data than before and can give to the user a representation that makes semantically sense, like showing only “real” notifications in the notification area.

Now the hidden items are a menu, because since an hidden item means it has no notification value, it just have an “interaction” one. so you probably need to access it just to trigger a function, like accessing one of its menu items (that will become a submenu of the main menu) and not anymore.

This design is a radical departure from the previous one (I would go as far as saying that is not a systemtray anymore, or at least that should be the target), so in the current Plasma widget there will be no room for the old behaviour anymore (so no configuration option to make it behave like a totally different widget, that should indeed be shipped as a different widget). However, the modular nature of Plasma, makes it really easy to replace the widget with a different one, maybe derived from the 4.4 branch (that by the way will stay buildable for the whole 4.x lifetime), so if there will be enough demand, rest assured a different widget for your needs will be available somewhere.

Small systemtray change


And now a new micro feature for KDE SC 4.5 πŸ™‚

Since today you’ll note that the expand button on the systemtray got rotated: weird isn’t it?

closed 4.5 systray

That is because it doesn’t expand anymore the systray to show hidden icons, instead when you click it, this is what happens:

opened 4.5 systray

There is a popup menu with all the hidden items in it, perfectly interagible and with a text label near to them: the rationale of this change is simple:

  • Hidden icons are rarely seen, it could be hard to recogniza them when you need one, so the label is very helpful
  • Often you expand the panel only to access a function of an hidden icon, then you don’t need te expanded systray anymore
  • Expanding the systray the unhide button actually moves, so it’s not immediate to close it again
  • When the systray is open, there is no way to distinguish icons that are norally visible and hidden

This has been done pretty early in the 4.5 cycle, so it’s still open for change, feedback and the due bugfixes πŸ™‚

Pretty system tray: not just about icon themes


It’s good to see other parts of the OSS community looking at the current state of the X system tray and not be satisfied at all, it’s good because as you can see from this blog, i think the current approach is really really limited in many ways, as it was explained several times

This time is about look… now, the idea of having monochrome systray icons is actually quite good, but is quite a pita with the current protocol and actually a good use case for the new one.. why?

Let’s say we have a black panel (as the mockup of jono’s blog), so it’s reasonable to expect we want white icons, but what about if we suddenly change our color scheme to a light colored one? (or plasma theme in case of KDE)
Of course the icons will become invisible, so we could need to change all of them to another theme on the fly, and this could mean also that those icons can’t belong to the system wide icon theme, or we could have to change the global theme just for the systray, that’s no good, right? πŸ™‚

Now, the current systray protocol requires that is the application itself draws its own icon, and this theme-dependent icon color switching is kinda possible (just open the configuration of the panel… by every application) but it’s really clumsy and not cross desktop at all.

The dbus based systray protocol we’re working on requires instead that is the systray the one who paints all the icons, and being part of the panel of course it knows well what the color scheme is.
The icons can be sent in Dbus by data, passing all the icon bytes themselves and in this case of course we can’t do much more than painting what it arrives, but the recomended way is to just pass the icon name (following the icon name freedesktop spec of course) and in this way we can decide where to pick this icon, we could have systray-specific icon themes dependent from the color scheme (falling back to the system wide one of course)

Now, I don’t know if we’ll actually implement a thing like that and if it’s worth the effort, but it’s a while we are talking about that thing and i think soon or later I’ll give this idea a spin πŸ˜€

Dissecting a tray


This is another pretty long post on the new system tray. Since the last post things have cleared up a bit (and i hope the api it’s a liiiittle bit more stable too) so i think times are ready for a slightly more technical description of all the machinery there is in place.

So, what are the parts of the system tray spec and more important how to use it and port existing applications?

First of all, the protocol is totally based upon dbus, so examining what are the registered services let’s see what are the (three) actors involved (yes, eventually some day those org.kde.* will become org.freedesktop.* :D):


every application that wants to use the systray has to expose this service, that will be called org.kde.NotificationItem-pid-index, where pid is the application pid and index is an unique thing that ensures no duplicate names, so an application can even register more item it it wants.

This thing is what defines everything that a system tray icon was and a bit of information more: it exposes the icon, a tool tip, the category of the item (status of a generic application, communication related, system service or hardware info) and the status: is it idle? is important that is visible? or is it really important to require user intervention?

It offers also some actions to interact with: activate, secondary activate, context menu and scroll. Notice how it doesn’t talk about left or right buttons, because right now we are providing a thing that looks like a system tray, to have a smooth transition, but we are not anymore forced to use that, we can have for instance some of the items embedded in the taskbar or have different representations, maybe interacted with the keyboard or who knows…


A system tray can come and go, for instance in Plasma the applet can be added or remove or the plasma process can be restarted, moreover the application can run in an environment that doesn’t (still:) support the protocol, so it’s needed something that keeps track of registered items and registered hosts for items (there can be more), all the system tray instances will register themselves here and take from here the list of items registered (NotificationItem implementations must register here too)

When the org.kde.NotificationItemWatcher is not up and running or it does not have instances of org.kde.NotificationHost registered all the items must automatically fall back to the traditional xembed type of icons


This service is registered by the system tray itself, it doesn’t offer properties or functions, it’s just used by the system tray (or whatever thing that can display an org.kde.NotificationItem) to announce its existence to the watcher to make possible to be automatically unregistered when the systray is closed (even if it crashes)

There can be an arbitrary number of hosts registered, to make possible both more simple things like having a system tray for each monitor in a multi monitor setup or more interesting stuff, like offering a different representation for different items category, for instance:

  • Putting the hardware status items and system services in a traditional tray, and we will be sure only that low level stuff will be displayed here
  • Integrating the application status items with the taskbar, we could perhaps display the minimized tasks without text in this case, or collapsing them in a popup menu, or whatever a brilliant idea will come πŸ™‚
  • Collapsing all communications related items in a single item into the panel, that would be a “messaging center”, where i don’t care if messages are arriving from kopete, kmail or konversation, i only want to know what people are saying to me…

Those are just abstract ideas for now, it’s not said that they will be implemented in this way or that this description is necessarily the best way to go, it’s just a little scenario to provoke some thinking on what is the best way to go and to not take as a given that the current way is indeed the current one, time will tell, what counts for now is that we are no more forced to display this stuff in a pre determined way.

Last but not least, where is the code?

System tray plasmoid and kded

The system tray plasmoid is basically the org.kde.NotificationHost part that does all the interaction with org.kde.NotificationItem and includes full support to the spec for KDE 4.3, it can also be configured to show only certain categories of items, giving a first implementation of the ideas i talked before (i.e. one systray for hardware info, one for application status etc.)

The plasmoid ships also a kded that implements the org.kde.NotificationItemWatcher part, if the daemon goes down, or all systray plasmoids go away, all the items becomes traditional system tray icons on the fly.

KNotificationItem library

This is the client library to be used in place of KSystemtrayIcon (with a very similar api) it takes care of all the dbus talking and is quite simple to use, it just offers some functions to set properties like icons and tooltips and some signals to notify about the various types of activation from the user.

This will go into extragear on the next few days, so applications can start to experiment with it, keeping in mind that is still experimental. After 4.3, it will head into kdelibs for KDE 4.4, at that date and time it will be completely api stable.