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.