Bug 1218056

Summary: System tray icon support for Plasma 5
Product: [Fedora] Fedora Reporter: lpugoy
Component: plasma-desktopAssignee: KDE SIG <kde-sig>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: dvratil, jgrulich, kde-sig, kevin, ltinkl, rdieter, than
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-04 08:51:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description lpugoy 2015-05-04 07:23:28 UTC 
Description of problem:
The xembed method of implementing the system tray was deprecated in Plasma 5. This results in some applications missing a system tray icon. The KDE developers have defined patches for Qt that should be applied for this case (http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/), but it doesn't seem to be implemented in Fedora 22.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Install a Qt based app that uses the xembed method like Insync (www.insynchq.com).
2. Run the app.

Actual results:
No icon in the system tray.

Expected results:
An icon in the system tray.

Additional info:
Comment 1 Daniel Vrátil 2015-05-04 08:51:27 UTC 
Installing plasma-workspace automatically pulls in sni-qt, which takes care of embedding the icon for Qt.

We do ship those patches you mention in our Qt 4 and AFAIK all Fedora Qt 4 apps show their systray icons just fine in Plasma 5. You however ship your own bundled copy of Qt, which makes this your problem not ours, so I don't really see the point of this report...

Anyway, couple hints:
  1) does your bundled copy of Qt 4 have the patch referred to in the blog you linked?
  2) does your proprietary application honour QT_PLUGIN_PATH (where the sni-qt plugin is installed)?
  3) if you rely on sni-qt, your package should have it in dependencies and not rely on *us* doing that for you in some other packages
  4) if your application is 32bit-only, you need to pull sni-qt.i686 even on x86_64

Marking as invalid, feel free reopen if you can reproduce the problem using Qt provided by Fedora.