Wolfgang Bauer wrote:
I installed plasma5-workspace (and -libs and -lang packages) from your repository. Unfortunately I see no improvements for Java applications (tested with the "tray icon demo") and for Pidgin 3.0.0devel. Both are unable to show the context menu. This was not supposed to fix the mouse click problem. It should fix resizing of old-style icons for some applications, GTK in
Am Dienstag, 1. März 2016, 21:45:43 schrieb Bjoern Voigt: particular.
As mentioned, Java applications (and Pidgin 3.0.0 apparently) ignore the fake mouse clicks xembedsniproxy sends to them.
The reason for this is not known yet, someone would have to dig through Java's code to find out what exactly it does and why it ignores those fake events. And that really means *Java*'s code, not the Java example you posted.
Pidgin 3.0 probably is a different story (I don't think it's a Java application, is it?), although it might do the same as Java.
Doesn't Pidgin 3.0 support SNI natively? Maybe via libappindicator3-1? (try to install that) That would be preferable anyway instead of relying on a hack. At least 2.x does have a SNI plugin AFAIK. They have an optional Ubuntu Unity plugin, which is difficult to compile on non-Ubuntu distributions because of all the missing dependencies. Tray icons are not mentioned in the plugin. I asked the Pidgin developers here https://pidgin.im/pipermail/devel/2016-March/023987.html about the issue described here but I am waiting for a response.
Pidgin 3.0.0devel's icon is still very tiny. Ok, so that patch doesn't seem to help in your case either. And as mentioned, it completely breaks KDE3 applications here. They are either tiny or nearly invisible. Compatibility with KDE3 is not an issue for me. Today I uninstalled my last KDE3 application (Arts).
You cherry-picked something from plasma-workspace (master branch). Yes. xembedsniproxy is part of plasma-workspace since 5.5.
I tried to compile xembed-sni-proxy directly from master branch. It should be usable without updating the rest of plasma5-workspace. That's old. That's basically the version we shipped stand-alone in the package xembed-sni- proxy to be used with Plasma before 5.5. No, this was a misunderstanding. I meant the subdirectory plasma-workspace/xembed-sni-proxy.
And if I understood you right, you cherry picked some patches from master branch and you compiled a patched plasma5-workspace package. And I wanted to compile plasma-workspace/xembed-sni-proxy without all the other plasma-workspace directories.
You can just as well install our xembed-sni-proxy package and ignore the conflict. Or, to avoid it getting overwritten by an update, extract the package (with Ark e.g.) and move the included usr/bin/xembedsniproxy to /usr/local/bin/. I already tried your full plasma5-workspace* packages with the described results.
I found FindXCB.cmake in the net, but not XCBConfig.cmake or xcb-config.cmake. Have a look at the BuildRequires in our package: https://build.opensuse.org/package/view_file/KDE:Frameworks5/xembed-sni-prox... (use "zypper wp xxx" to find out which package provides xxx)
You seem to miss libxcb-devel... Thanks for the hints. But I have libxcb-devel installed. I also manually checked all the required packages from the recommended xembed-sni-proxy.spec file (e.g. with something like "rpm -q extra-cmake-modules" or "pkg-config --version xcb-xfixes"). Currently I do not know, how to test the cmake requirements (e.g. "BuildRequires: cmake(KF5WindowSystem)").
I probably have to learn some Cmake debugging. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org