Hello,

There are certain technical limitations due to which xembed based systemtray can not be implemented. For more information please read http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/ and if your favorite app is still using xembed based system tray please refer http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ to setup wmsystemtray.

Closing this as RESOLVED WONTFIX

Thanks!

Perhaps the technical limitations prevent a pretty or perfect solution that the developers of the new shiny Plasma Next have in mind. However, I bet for a serious Plasma Next developer, it would be an easy exercise to implement a system tray applet featuring the functionality of the "old" Plasma, even if an ugly, upscaled version of 22x22 icons without supporting the new features. But they just won't, presumably because it is violating their "higher" design principles. 

Too bad that this is really annoying and frustrating lots and lots of users out there. Very easy to confirm this by google. But hey, who cares about the users anyway? How would they know what's best them? Windows 8 anyone? Gnome 3? Sad to see that the desktop environment of my choice has become infected with the same virus. Breaking functionality for "pretty"? Really? I think "WONTFIX" is just an ignorant decision. 

And by the way, the wmsystemtray solutions proposed above are MUCH uglier even! Because they cannot be embedded into the system tray, they will have to be located in their own window. Seriously? So now I have to close all windows in order to get to the systray? How is that compatible with your ambitious design goals?

I know what you are going to propose: it is open-source, so if you don't like it, fix it yourself. As it happens, I can't. I am not good enough a developer to do it. And I am guessing that for a Plasma Next developer, this would be half an afternoon to implement, if even that. And I think the only reason that this is not done is some principle, and not because it cannot be done. You are proposing/releasing the new version to the community, and to some extent the community lives at the developers' mercy not to break the product. All I am asking is that the new version of the product (Plasma Next) is released without purposely broken functionality.

Hannes, do you really think that your rant will change anything? Do you think that yelling at us will make us say, "ah right, Hannes is right, we can do it!"? Do you think we haven't been aware of the issues it causes? Do you think we didn't try everything to make the situation pleasant?

Just consider that my blog post is from March last year, while we released in July. That's several months for people to catch up. We asked distributions to help us here. Some did, some didn't. If it doesn't work on your system: please take it to your distribution for not applying the required changes.

Indeed, where plasma 5 is otherwise a flawless migration, this is the main pain point (the ubiquitous dropbox app seems to be a hit-or-miss ; teamviewer did not migrate yet ; old apps like e.g. lotus sametime never will)

Back to the technical points:

@Martin:

* "Also getting the xembeded window integrated into our QtQuick based system tray is not the most trivial task." Can you detail a bit what are the technical issue ? Assuming an X11 only solution, if Wayland is too complex.

* "please take it to your distribution": what can distribution do (I mean what can they do that others cannot, of course everyone can give budget/manpower for implementation) ?

* what is the feasibility of a hybrid aproach, like taking wmsytemtray or stalonetray ; and having them "talk" with plasma to move with the system bar (for me this is the main problem with the current workaround, as I connect to external displays frequently) ?

Thanks a lot for your input, and great work on Kwin !

> Can you detail a bit what are the technical issue ?

I'm not in the mood to explain it - again. Can you please trust the maintainer of most X11 dependent applications in Plasma on that one?

> what can distribution do

There are patches to get applications work properly. E.g. for Qt 4 applications (such as dropbox) there is the sni-qt patch which turns the QSystemTrayIcon into a StatusNotifierItem. Distributions need to provide these packages.

> what is the feasibility of a hybrid aproach, like taking wmsytemtray or stalonetray

My personal solution (Debian unfortunately refused to take the patches for sni-qt) is to use wmsystemtray and use a kwin rule to statically put it next to the panel.

> Can you please trust ...

Of course ! It's more curiosity anyway (and politics: having an explanation almost nobody can understand somewhere public would help with the uproar and the "they don't want to" frustration)

> Distributions need to provide these packages.

Do you remember which camp is fedora in ?

> My personal solution (Debian unfortunately refused to take the patches for sni-qt) is to use wmsystemtray and use a kwin rule to statically put it next to the panel.

That's exactly what I want , but with a "dynamically" instead of "statically" i.e. detect tray applet change or at least screen resolution change... I don't think the window rule can be dynamic even with "force" and the plasma tray does not appear in a kwin script in workspace.clientList() (at least did not in plasma1), so not so easy, but I'll try again (and probably ask stupid questions in the forum)

Martin, 
Thank you very much for your very fast answer. I understand that my posting is a "gloves off" kind of contribution, and I have to admit it is less diplomatic than I usually try to be, and probably not a smooth way to start a discussion. I realize that I was too undifferentiated and emotional for a forum like this; my tone was not appropriate, and I apologize for it. Let me try to strictly stick to facts and arguments now. 

What seriously puzzles me is a statement you make in your very own blog on 2014-03-04: "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." I simply think that the latter is a highly debatable statement. 

What this statement suggests to me is that it would very well be possible for the Plasma Next developers to implement xembed, but it was simply decided not to do it. And this is the very decision I am questioning: the core developers working on a new version not being in charge of "keeping compatibility with the legacy system". Of course, if someone else would have picked up the issue and come up with a solution, this would have been fine, as well. Except it did not happen. Trying to get ready for Plasma Next I have periodically been looking around for more than 1 year whether someone has developed an acceptable solution, but all I find is blog post after blog post with users running into the issue. So if no one else found a solution, and the core developers think it would be so feasible to do this within the Plasma framework, wouldn't it be a good idea if they provided a fix?

In your response above you state "Do you think we didn't try everything to make the situation pleasant?" — Is that not in contradiction to your blog post, where you make it sound like implementing would not be such a big deal? 

Let me take another point of view. If stalonetray (which is more than 10 years old) and other projects manage to bring up xembed icons inside a dedicated window, why wouldn't it be possible to do the same thing for a (legacy) systray app in the taskbar? For me this would be an ideal solution, as it would allow the "old" and the "new" systray icons to peacefully co-exist, which I always consider ideal for some kind of smooth transition. It would not break functionality and give everyone time to move. For me  this would very much be in the linux spirit

As I mentioned, I am not a developer, and I have no useful expert knowledge, but it just seemed like this should not be too difficult to implement. Please correct me if I am wrong, but my impression was that this was thus more like a policy issue (which I saw no good reason for). When I googled again today and ran into this bug report, which someone cared to provide, and pretty much the only response was "WONTFIX", then I just thougt that thaiis was too much.

> > Distributions need to provide these packages.
> 
> Do you remember which camp is fedora in ?

Fedora should be fine for Qt apps, but GTK maintainers refused to take the 
patches for their packages

On Monday 30 March 2015 23:00:54 you wrote:
> So if no one else found a solution,

No, it just means that nobody else cared to invest the time or the money to 
hire people to implement it.

> and the core developers think it would be so feasible to do
> this within the Plasma framework, wouldn't it be a good idea if they
> provided a fix?

I'm sorry to say, but probably I am the best suited dev to work on it from the 
active Plasma team. My focus is currently completely on Wayland and working on 
legacy code base which cannot be used in Wayland at all is nothing I'm
a) interested in
b) have time for

Can this be reopened so we can add votes to it? Or is the decision final, regardless of how many users want it?

For the reference, Debian just rolled in Plasma 5, and I found a trayer tool which provides a workaround for legacy applications.

I agree that there is no point to use implement insecure solutions however, and if you are affected by this, contact application developers about not using xembed.

Maybe interesting for other people: plasma-workspace >= 5.5 seems to contain a workaround which provides a program "xembedsniproxy" making (a not-so-beautiful but  functional) version of xembed-based tray icons available in the plasma tray. (This is at least true for the arch linux packages.)

RESOLVED WONTFIX?

actually fixed since Plasma 5.5, see https://www.kde.org/announcements/plasma-5.5.0.php