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.
What would a 3rd party do to get xembed support if they needed it?
Lets say one is a system integrator and your customer has applications that will not be updated (as usual with custom proprietary software).
But you, as the system provider, would really like to offer an upgrade for the rest of the system.
Would that be better done with a stand alone application, probably running as an always-on-top window, or, assuming it is using Qt5, could it somehow be integrated into a Plasma panel?
I doubt that it would be possible to integrate it into a Plasma panel at all or only with an amount of work a system provider would not be willing to do.
What I thought about in case that we get too much negative feedback about “Skype doesn’t work any more” is to write a standalone application which provides the systray. It should be window type dock, so that it can be a panel and thus easily be placed next to the remaining systray.
Ah, I see, so as an external application that behaves similar to a panel. Makes sense.
I am almost certain that this will be needed but I am not sure if you will explicitly hear about it. This will mostly affect “enterprise” installations (companies, governmental institutions, etc) and those are unlikely to report directly to you.
My suggestion would be to have this available but not autostart it. Enables admins or system integrators to enable it when needed, but does not get int the way on private machines
But how should they know about it without asking us?
Documentation, e.g. how the also find out about Kiosk, etc.
And it is more likely that people will first ask on our user support channels than immediately file bug reports.
Solutions that are available and documented can just be pointed out by any other participant on the channel, doesn’t require any developer attention until that solution does not work either.
Such applications have existed for years, e.g. stalonetray. It’s a very easy (yet not very pretty) workaround if you really need it.
‘This will mostly affect “enterprise” installations ‘
No (sane) enterprise installations is going to deploy Plasma Next in the near term. They will stick with Plasma 4.11.x for stability and support, and by the time they move to a Qt5 based Plasma (2-3 years after first release), applications such as skype should also have made the jump.
As for in-house applications or 3rd party proprietary applications: not many rely on system tray functionality in the first place, and those that do will hopefully get retrofitted in the years to come.
Do you think it would be feasible, assuming the application uses Qt4’s QSysTrayIcon API, to make a shim library that through LD_PRELOAD would redirect calls to make a systray icon into a custom implementation that exclusivelly used the notification API, even if lacking the remaining meta-data?
It is a hell of a hack, but if feasible, I think it’d be possible perhaps to make at least some legacy Qt apps (and at least Skype, as I’m assuming it uses the Qt API to make the tray icon on Linux) work somewhat acceptably with the new Plasma tray.
I do know this wouldn’t work with applications which used xembed directly, but I’m assuming Qt4’s API has enough data to make it somewhat work.
for Qt4 there’s sni-qt used by Ubuntu. We just need to get it into other distributions.
Nice work! I hope that we in Ubuntu will be eventually able to use this QPA backend instead of sni-qt.
I would be glad if it’s used – less code duplication is a good thing. But I have to point out that my implementation makes use of the KDE Frameworks. On a technical level that shouldn’t be an issue, though.
Why does it need KF5? It should just take a menu and export its contents over D-Bus, shouldn’t it?
“Though it will take until Qt 5.4 till the feature will be working properly”
Has the team considered this as a possible reason to not release a version marked “stable” before then?
The system tray is a critical component to desktop workflow for many, and having things like skype break is going to be a deal breaker for many. That first impression is not easy to shake; prior experience in that regard is why a focus on “works as well as 4.x out of the box” was a focus in discussions last year.
Tech previews, developer versions, etc. would be affected by such expectations, but a release marked “stable” would, and that would deeply risk the reception of Plasma Next as well as the future market share of Plasma.
Well there are not many Qt 5 application yet (e.g. Skype is still Qt 4 based). So the fact that the Qt 5 version doesn’t support it yet is not a show stopper. Qt 4 support is more important, but I hope that we can make use of sni-qt used by Ubuntu.
I don’t know about the other distros, but at least in openSUSE we (the openSUSE community KDE team) have made the decision that Next will be available as an option for the adventurous for the upcoming (13.2) openSUSE version. For 13.2+1 we will re-evaluate in due time.
Couldn’t some LD_PRELOAD solution for old xembed system tray applications be devised? For low resolution icons perhaps some simple upscaling could be applied to make it look a bit less sh**ty.
Do you think it’s worth to write a human interface guideline about tray menus/icons? I think about when to apply, how to interact with left/right mouse button, etc., or is the technical limitation sufficient to make the UX consistent and straight forward?
with status notifiers the complete control is withing Plasma, so we already have the guidelines. For legacy system tray we cannot do much as KDE applications are already using status notifiers for quite some time.
Unfortunately, most GTK+ applications in Fedora will probably never support the new status notifier protocol. The Fedora maintainers for those packages are the same GNOME upstream developers who rejected libappindicator upstream (claiming it is buggy and unstable) and refuse to build their Fedora packages with libappindicator support. Therefore, no more XEmbed support will mean no more interoperability with GTK+ applications. 🙁
In addition, Qt 4 applications will be around for a long time to come, so we will also have to patch Qt 4 with that Kubuntu patch that Qt upstream refused to merge for stupid reasons. (They don’t want to do a 4.9 release, and they don’t want to accept the change into 4.8 because it is a new feature.) And I will miss my KDE 3 KSensors that I still use. (There is still no comparable plasmoid.) 🙁
Perhaps once Fedora sees how useful it can be, Red Hat will write their own implementation for GTK. Or, perhaps the use of libindicator on every other disttribution can force Fedora to use it.
Maybe it’s worth to try it nevertheless. It used to be about packaging something not used by anything in GNOME. Now with Plasma relying on it, the situation might be different and I doubt that the GNOME maintainers in Fedora want to break Plasma.
Anyway your comment showed me that I should send a mail to packagers mailing list with a summary what distros should ship to make the transition smooth.
I have sent this to the Fedora devel mailing list:
https://lists.fedoraproject.org/pipermail/devel/2014-March/196343.html
overall that sounds quite good from the infrastructure side given that you already have libappindicator. I thought that even that is missing.
Btw. also for Plasma Current with appindicator the application will integrate much better 🙂
The problem is that almost nothing is built against libappindicator in Fedora. According to repoquery, the only package built against libappindicator is gnome-rdp (a Mono app from SourceForge where upstream made the dependency on libappindicator-sharp mandatory), libappindicator-gtk3 is entirely unused.
And the fact that it would also improve the integration into current KDE is a good point, I had been meaning to point that out, too, but somehow forgot about it. I’m going to mention it, too.
Theoretically, one could implement a second tray widget which is using always X or XWayland in combination with xembed for users which will be pissed, because old apps don’t work anymore like they were meant to be.
As far as I understand this, this will lead to breakage of Java applications (besides others) that rely on the standard Swing SystemTray Icon (such as Jitsi, for example).
What is your plan regarding this?
Will there be bindings for Java?
There are no plans for Java. I personally do not have Java installed as I consider it as a huge security risk for any desktop system.
Well, I do think it would be highly relevant to at least support an easy transition for Java, and maybe other significant languages and their according libraries.
Breaking applications that rely on the legacy system tray _and_ not allowing the software authors to port them easily, will probably have negative impact on the confidence people have in the reliability of KDE (and maybe GNU/Linux in general). This is especially an issue in public institutions and companies. *
Also, just having Java applications running is not, as far as I can see, a security risk – allowing Java applets might be one.
I see that it is hard for small companies and volunteers to do all this library work. (Btw.: I very much appreciate your what you do! 😉 ) So: Do you think it might be possible to inform other companies like SUSE or Red Hat about the negative imact it would have for their business, if this work is not done?
I mean it is just on their interest do satisfy the user’s urge for reliability on the Linux Desktop.
The problem with legacy is that at one point or another you have to remove the support for it. We introduced statusnotifiers five years ago, so how long should we wait with dropping support for legacy? How much time do we have to give to frameworks like Java to catch up with it?
All distributions are aware of the change. There is no further need to contact SUSE or RedHat. For those who really need it: there are existing applications providing a legacy systemtray. This also runs under Plasma.
The new system is access through D-Bus, there are D-Bus bindings for Java.
I also find it likely that some system integrator or OSV will create an XEmbed capable “tray app” to be used for legacy applications on modern workspaces.
Actually some even exist today, see http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/comment-page-1/#comment-66957
A way more interesting question IMHO regarding Java will be whether Oracle has anyone working on Wayland support already
The new system can most likely be implemented in the Java platform adapter.
The whole Java system integration stuff is highly plugin based.