In the past the system tray was implemented using the xembed specification. An application which wants to use the system tray creates a small window which gets embedded into the system tray. This means that the control over this area belongs to the application and not to the desktop shell hosting the system tray.
The result is that each item in the system tray may behave differently. Some set a different cursor, thus the cursor is flickering if you move from one icon to another. Some open/close the application when clicking the icon, some might provide a context menu on right mouse click or interact with further input events. But what is present in all cases is that there is no consistent behavior. From a user experience point of view this is very bad as the users learn that the system is inconsistent and works in an unexpected way.
Some years ago the Plasma hackers started to address these issues by implementing a new specification called Status Notifier. This specification got also adopted in Unity/Ubuntu as the Application Indicator. The new specification addresses the issues outlined above as the control is moved to the hosting desktop shell. This allowed us in Plasma to provide a consistent look and feel by using the monochrome icons and controlling which items to show when.
But still we supported the xembed system tray specification for legacy applications which were not adopted to the new specification. This means that all the issues are still present. It’s still possible that an item behaves completely different because it’s using the legacy protocol.
When we drafted the plans for the new implementation of the system tray in Plasma Next we of course also discussed the future of the xembed based implementation. It was a challenging topic as we want to go to Wayland and obviously an xembed based system tray icon won’t work on a Wayland powered system tray (yes in theory it could work through XWayland). Also getting the xembeded window integrated into our QtQuick based system tray is not the most trivial task.
Also some of the design aspects just don’t work with the legacy system tray. We want to support reasonable dpi and xembed items are hard coded to 22×22 pixels, that’s probably a lot of fun on a high dpi screen. We also want to categorie the system tray items, so that they are logically grouped. For that the status notifiers allow to tell us that it’s an application item and whether it’s currently passive, active or demands attention. This gives the host the required power to properly place the item. But with the legacy system tray we are just lacking this information and don’t really know what to do with an item.
When we discussed all these issues it became apparent that we do not want to invest the time in implementing the legacy system for Plasma Next. Nevertheless we do not want to break the functionality of existing applications. So we investigated ways of how we can ease the transition. KDE applications use the status notifier already and most GTK+ applications also use the appindicator library for unity integration, so they just work the way we want it. But for example the QSystemTrayIcon still uses the legacy system on X11. As it’s Qt there is also the QPA-API which allows us to provide Plasma-specific implementations through our platform theme. That’s the approach we decided to go: force any QSystemTrayIcon to use the status notifier API through our platform theme. Unfortunately the QPA-API was not sufficient for our needs and thus we had to extend it, which will be available in Qt 5.3. If Qt base is compiled with X11 support the QPA system is not used at all and the change to fix this slightly missed the 5.3 merge window. The last missing bit to get this work is in our frameworkintegration repository to implement the required API. This is currently under review which means that it will be available once we release our first release of Plasma Next. Though it will take until Qt 5.4 till the feature will be working properly. As a nice side-effect this also adds an implementation for QSystemTrayIcon on Wayland/Plasma.
Although we invested lots of time into making it work as smooth as possible there will be applications for which the system tray icon will not be working. Nevertheless, we decided to not implement support for it as we want to focus on the core and it was not justified to invest lots of time on an implementation only needed for a short period of time. Applications still using Qt 4 will hopefully soon get ported to Qt 5 and then the issue fixes itself. Overall from an end-user perspective this means that nothing really changes. The system tray is still going to work, in fact it will be better as all items can be scaled, themed, behavior adapted to input methods, logically grouped and much more. Nevertheless it’s possible that there are applications which still use the legacy protocol and that will break. In case it’s an open source application it will be easy to fix and we as the Plasma team are happy to help as much as we can. And in any case Plasma is a very flexible framework allowing you to implement an alternative system tray which supports the xembed system tray. It doesn’t have to be the core team which keeps the compatibility with the legacy system.