java tray icon doesn't work, transparent icon and no menu on mouse click xembedsinproxy output: kde.xembedsniproxy: trying to dock window 27263296 kde.xembedsniproxy: adding damage watch for 27263296 kde.xembedsniproxy: Skip transparent xembed icon for 27263296 "JavaEmbeddedFrame" kde.xembedsniproxy: Skip transparent xembed icon for 27263296 "JavaEmbeddedFrame" kde.xembedsniproxy: Skip transparent xembed icon for 27263296 "JavaEmbeddedFrame" kde.xembedsniproxy: Skip transparent xembed icon for 27263296 "JavaEmbeddedFrame" when I click or scroll on the transparent icon: kde.xembedsniproxy: Received click 3 with passed x*y 1121 732 kde.xembedsniproxy: Received click 1 with passed x*y 1121 732 kde.xembedsniproxy: Received click 2 with passed x*y 1121 732 kde.xembedsniproxy: Received click 7 with passed x*y 0 0 kde.xembedsniproxy: Received click 6 with passed x*y 0 0 on mouse over: appear JavaEmbedFrame tested with jdownloader 2 on plasma 5.4.3 + xembed-sin-proxy backport Reproducible: Always
Created attachment 95565 [details] tray bug
What app?
I used jdownload 2 for test (http://jdownloader.org/) instead if you test this https://docs.oracle.com/javase/tutorial/uiswing/misc/systemtray.html, the icon is visible, but the left/right click aren't processed correctly
Created attachment 95603 [details] test TrayIconDemo
Thanks
java systemtray(Tray Icon Demo) requires: 1, left double click to activate. 2, when rightclick happened, the tray icon window must be 'topmost' (I guess), otherwise, menu will not pop up. The root cause is: SNIProxy.cpp create a "container Window" to embed 'tray window', and make the 'container window' transparency(thus invisible), and when click happened(Activate/ContextMenu..), SNIProxy will 1, set the container Window topmost. 2, move it under the mouse cursor. 3, send PRESS/RELEASE event to 'tray icon window'. 4, then set the container Window below others. For Java 'TrayIconDemo', above steps only send 'single click' to 'tray icon window', then "window stack mode" changed, even user clicked twice, that's 'two' single click, not 'double click'. And I guess, the 'right click' issue is also related to this, since after workaround, it works. Here is a workaround patch to delay the stack mode changing for enough time(at least long enough for double click). It should work, but not very well, the remaining issue is 'you may need one more click to set the window topmost first sometimes and click event is lost'. A better way to fix this is 'gain focus automatically and set the container window topmost', but it's really not easy. ======= diff -Nur plasma-workspace-5.4.3/xembed-sni-proxy/sniproxy.cpp plasma-workspace-5.4.3new/xembed-sni-proxy/sniproxy.cpp --- plasma-workspace-5.4.3/xembed-sni-proxy/sniproxy.cpp 2015-11-23 21:41:31.870060993 +0800 +++ plasma-workspace-5.4.3new/xembed-sni-proxy/sniproxy.cpp 2015-11-23 21:41:19.785060877 +0800 @@ -196,6 +196,8 @@ SNIProxy::~SNIProxy() { QDBusConnection::disconnectFromBus(m_dbus.name()); + auto c = QX11Info::connection(); + xcb_destroy_window(c, m_containerWid); } void SNIProxy::update() @@ -375,13 +378,13 @@ xcb_send_event(c, false, m_windowId, XCB_EVENT_MASK_BUTTON_RELEASE, (char *) event); free(event); } -#ifndef VISUAL_DEBUG + //Do not move window down imediately, sometimes, tray requires double click. + QTimer::singleShot(1000, this, &SNIProxy::downContainer); +} + +void SNIProxy::downContainer() +{ const uint32_t stackBelowData[] = {XCB_STACK_MODE_BELOW}; + auto c = QX11Info::connection(); xcb_configure_window(c, m_containerWid, XCB_CONFIG_WINDOW_STACK_MODE, stackBelowData); -#endif - } - - - - -// +} diff -Nur plasma-workspace-5.4.3/xembed-sni-proxy/sniproxy.h plasma-workspace-5.4.3new/xembed-sni-proxy/sniproxy.h --- plasma-workspace-5.4.3/xembed-sni-proxy/sniproxy.h 2015-11-23 21:41:31.861060993 +0800 +++ plasma-workspace-5.4.3new/xembed-sni-proxy/sniproxy.h 2015-11-23 21:26:28.630052291 +0800 @@ -46,6 +46,7 @@ SNIProxy(xcb_window_t wid, QObject *parent=0); ~SNIProxy(); + void downContainer(); void update(); /** By the way, the 'container window' must be destroyed in destructors. Even 'undock' happened, the container window will still be there, under most circumstance, it will keep below(that's ok, just a transparent and invisible window leak), but it also may keep topmost(rarely, but I encountered), since the maximum size of containerWindow is 48x48, it may cover on adjacent status items, then other statusitems will not accept events anymore.
WRT the destructor, good spot, thanks. For the other part, maybe we need to be sending some sort of focusevent to the embedded window before we send the click? I used to have a delay before the stack below, but with compositing off you see this large block moving about. I guess it's better than clicking not working, but it'd be better if we could avoid it.
CJacker what's your real name so I can put it in the commit log with you as the author?
(In reply to David Edmundson from comment #8) > CJacker what's your real name so I can put it in the commit log with you as > the author? You can use 'Cjacker Huang' if you insist to leave that in commit log:-) I am an old KDE3 developer(informal) and recently back to KF5, and to fix some bugs I encountered, so I am even not familiar with the 'git reviewboard', sorry for that. I tried other ways to fix this issue, but have some difficulties: 1, How to get the current statusitem size? if we can get it, we can resize the 'tray window' and 'container Window' just to that size(since the status icon is in that size) and keep them always on top(cover on status item icon), but still have focus issue, maybe 'mouse in window' to gain focus. I noticed, with my laptop(thinkpad X250, 1366x768), the maximum size of status item is 24x24?(I did not check the codes), even I continue increase the panel height, the size of statusitems will not be increased with it. but if I decrease the panel height, status item will become smaller. 2, How to get mouse enter/hover event from statusitem interface, I checked the SPEC, seems no way to get it. For traditional system tray manager, It done a lot about focus in/out management, but for 'xembedsniproxy', I can not figure out an easy way to do that(there is one container window for each legacy system tray, how to manage all of them?). About non-composting environment, the better way is to use window mask to create irregular window just as the icon outline shape? but at first, it need to: 1, fetch the icon correctly. 2, know the current size of status item.
Created attachment 95752 [details] Workaround for java systemtray
Created attachment 95754 [details] Workaround for JDownloader2 and Bug 355684
(In reply to Cjacker from comment #11) > Created attachment 95754 [details] > Workaround for JDownloader2 and Bug 355684 This patch based on the patch of https://bugs.kde.org/show_bug.cgi?id=355919
I have the same problem with clicks being ignored on tvbrowser's system tray icon, also a java app. I tried the patch from comment#10 (on top of the latest version from the xembed-sni-proxy github repo), and it basically works. There's still a problem though: it seems the first mouse click is still ignored, I have to double-click for a reaction, also for right-clicks. Other XEmbed icons that worked fine before (regarding mouse clicks) still work fine. I tried with ksensors, a KDE3 application.
http://commits.kde.org/plasma-workspace/41df1bdb8b478eb27fb424d201c075c76ec0ed5a With last commit the icon are now visible (at least for jdownloader), remain only the mouse input problem and the wrong title on mouse over.
*** This bug has been marked as a duplicate of bug 356500 ***
So I tried to start a java based app (DavMail for Exchange) and it's not embedding correctly in my system tray anymore. I tried to install the SNI Proxy package, to no avail: installed plasma5-workspace-5.5.5.2-12.1.x86_64 obsoletes xembed-sni-proxy Why was this dropped from 5.4?
You'll have to ask your distro for packaging details, but I can *guess* one reason may be plasma5-workspace-5.5.5.2-12.1.x86_64 includes xembedsniproxy itself (ie, it's no longer packaged separately).
Yeah, thanks for the suggestion. I thought about that, but then noticed that it doesn't work at all with DavMail, or other Java apps, so I was wondering if either something changed or wasn't included at all. It's probably the former. *sigh* KF5 has been a disaster, this is just one of them. I give up.