In system tray set Dropbox icon (or any other xembed icon) to always "hide". After system reboot this setting randomly resets itself to "Auto" in opensuse bug reporting comment #5 https://bugzilla.suse.com/show_bug.cgi?id=955146#c5 suggests . . . "it stores some number/id for those old-style icons, and apparently that number/id changes on every login. So the setting doesn't apply, and if you change the setting again, you pile up entries in the config file." in plasma 5.4.2 and 5.4.3 on openSUSE Leap 42.1 with xembed-sni-proxy the setting would reset across reboots approx 70 - 90% of the time. In plasma 5.5 it is much much less frequent but does still occur from time to time. Reproducible: Sometimes
QString SNIProxy::Id() const { return QString::number(m_windowId); } Heh, not surprising this doesn't work. At one point I had it use the title as a unique idenitifier, but apparently this caused problems for Wine apps where that wasn't set and apps simply didn't appear. I'm not sure what any possible fix here would be. Note that xembedsniproxy is designed only as a fallback for terrible applications that do follow modern speficiations, if apps are using this please file a bug report with them to update their software stack.
(In reply to David Edmundson from comment #1) > Heh, not surprising this doesn't work. > > At one point I had it use the title as a unique idenitifier, but apparently > this caused problems for Wine apps where that wasn't set and apps simply > didn't appear. > I'm not sure what any possible fix here would be. Sorry for asking/suggesting the obvious. But wouldn't it be possible to use the title, and only fall back to the windowId when the title is empty? Would at least fix this problem for most (non-wine) xembed icons I suppose.
having the same problem here arch kde 5.5.4
>But wouldn't it be possible to use the title, and only fall back to the windowId when the title is empty? Should be, slow part is the testing rather than the implementing. I'll give it a go in master and see what happens. My other thought was to make a string of the process ID and arguments from proc as that might also fix the wine case?
(In reply to David Edmundson from comment #4) > My other thought was to make a string of the process ID and arguments from > proc as that might also fix the wine case? The process ID would also change on each login, so probably not any better than the windowid... Or am I misunderstanding something?
I meant the process name, as in "dolphin" or "wine".
(In reply to David Edmundson from comment #6) > I meant the process name, as in "dolphin" or "wine". Ok. Yes, that sounds reasonable, I actually thought that myself already...
Git commit 1c70951abe9f52948b6e1c3ea0dc191997e26b2a by David Edmundson. Committed on 27/03/2016 at 16:22. Pushed by davidedmundson into branch 'master'. Use consistent data for xembed SNI IDs M +6 -1 xembed-sni-proxy/sniproxy.cpp http://commits.kde.org/plasma-workspace/1c70951abe9f52948b6e1c3ea0dc191997e26b2a