Hello, sorry, I'm afraid I'm not going to describe my problem well .... anyhow, I have current up-to-date suse 42.2 with plasma 5.8.x .. If I run stardict application which has (ugly) legacy icon, the icon is displayed but it's completely dead, no reaction from it on mouse actions ... I reproduced, that stardict and his icon behave both like they did for years - eg if I install some other standalone tray app (like stalonetray), the icon in the tray is working properly like it was working for years (including in kde 4) .. That leads me to the assumption, that something in kde regarding to xembedsniproxy is rotten ... Please poll me for more info if required, I'm really not good at debugging GUI apps .. If you wish to reproduce that, you can do it with stock suse 42.2 plasma5 and stock stardict, just after installing suse install stardict (reproduced on two separate boxes) .. regards, daniel
updated summary to specifically mention stardict. That said, I cannot reproduce this on fedora 25 using plasma-5.8.5, stardict 3.0.6 left click stardict systray icon shows stardict app window right click shows scan/quit options
(In reply to Rex Dieter from comment #1) > updated summary to specifically mention stardict. > > That said, I cannot reproduce this on fedora 25 using plasma-5.8.5, stardict > 3.0.6 > > left click stardict systray icon shows stardict app window > right click shows scan/quit options that is supposed how it shall work however it's not working like that in here ... good news are, that it's easily to reproduce at least for suse users (yes I know, I should report it also to suse bugzilla), you just install suse with its defaults (spill some weed around the enter button and let some poultry do the job because only you do is hitting next->next->next ....), install stardict and you have it reproduced ... regards ps. and thansk for your support on irc :)
Git commit 9df815e843a4385465fff0cb9a76ddc94ed35b38 by David Edmundson. Committed on 24/03/2017 at 09:35. Pushed by davidedmundson into branch 'master'. Inject mouse clicks from SNI to xembedded icons with XTest Summary: A certain toolkit doesn't register for mouse press release events because it now uses XI2 only. Injecting those directly to the window is too difficult, fortunately in the GTK3 case we can use XTest to send an event. Something I had previously chosen against using because it didn't work with something else (can't remember what). I now have a bit of code choosing which method to use, which will hopefully cover all cases. Code is a bit convuluted because the xcb version of xtest doesn't have the high-level method I want to use in it's API, so I just used Xlib version. Related: bug 362941 Test Plan: Ran my usual bunch of test apps: - xchat - a GTK3 systray demo I made - skype (A Qt4 app without SNI patches) All worked as before Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D5156 M +3 -3 xembed-sni-proxy/CMakeLists.txt M +26 -2 xembed-sni-proxy/sniproxy.cpp M +7 -0 xembed-sni-proxy/sniproxy.h A +32 -0 xembed-sni-proxy/xtestsender.cpp [License: LGPL (v2.1+)] A +28 -0 xembed-sni-proxy/xtestsender.h [License: LGPL (v2.1+)] https://commits.kde.org/plasma-workspace/9df815e843a4385465fff0cb9a76ddc94ed35b38
Please test with plasma master.
Git commit 7df184afa19f148c1cd09ae9588645bb2b4556fc by Wolfgang Bauer. Committed on 31/05/2017 at 11:36. Pushed by wbauer into branch 'Plasma/5.10'. [xembedsniproxy] Fix check whether to use XTest Because of C++'s operator precedence, '!' logically negated all_event_masks only instead of the whole expression. This resulted in the condition always being false and XTest never being used. Adding a pair of brackets fixes it. Related: bug 362941 FIXED-IN: 5.10.1 Differential Revision: https://phabricator.kde.org/D6048 M +1 -1 xembed-sni-proxy/sniproxy.cpp https://commits.kde.org/plasma-workspace/7df184afa19f148c1cd09ae9588645bb2b4556fc