[opensuse-factory] Legacy tray icons on Plasma Workspace 5.5.4
Could someone confirm, that legacy tray icons do not work as expected in Tumbleweed with KDE Plasma desktop? (Support for legacy tray icons is restored in KDE Workspace 5.4 or 5.5.) At first I saw this issue using Pidgin 3.0.0 (GTK+3, Pidgin development version). The tray icon is displayed very small and the context menu does not work. Pidgin is difficult to compile. So I searched a small example, which is easy to test: Here is a Java tray icon demo: https://docs.oracle.com/javase/tutorial/uiswing/examples/misc/index.html#Tra... Setup: * download and unpack the ZIP file * change Windows LaF to Metal LaF. The metal LaF is already there as a comment: //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel"); UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel"); * compile and run the demo: "ant run" or "ant run; ant jar && java -jar dist/TrayIconDemo.jar" The icon is displayed correctly. But the context menu does not work. My setup (standard Tumbleweed - openSUSE Tumbleweed (20160228) (x86_64)): * Plasma Workspace 5.5.1 * Plasma Framework 5.19.0 * Qt 5.5.1 /usr/bin/xembedsniproxy (from plasma5-workspace) shows messages like these: kde.xembedsniproxy: trying to dock window 130023428 kde.xembedsniproxy: adding damage watch for 130023428 kde.xembedsniproxy: Skip transparent xembed icon for 130023428 "JavaEmbeddedFrame" kde.xembedsniproxy: No xembed icon for 130023428 "JavaEmbeddedFrame" kde.xembedsniproxy: Skip transparent xembed icon for 130023428 "JavaEmbeddedFrame" kde.xembedsniproxy: No xembed icon for 130023428 "JavaEmbeddedFrame" kde.xembedsniproxy: Skip transparent xembed icon for 130023428 "JavaEmbeddedFrame" kde.xembedsniproxy: No xembed icon for 130023428 "JavaEmbeddedFrame" kde.xembedsniproxy: Scaling pixmap of window 130023428 "JavaEmbeddedFrame" from w*h 24 24 kde.xembedsniproxy: Scaling pixmap of window 130023428 "JavaEmbeddedFrame" from w*h 24 24 kde.xembedsniproxy: Scaling pixmap of window 130023428 "JavaEmbeddedFrame" from w*h 24 24 kde.xembedsniproxy: Received click 3 with passed x*y 1635 1050 kde.xembedsniproxy: Received click 3 with passed x*y 1635 1050 Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 29. Februar 2016, 17:28:54 schrieb Bjoern Voigt:
Could someone confirm, that legacy tray icons do not work as expected in Tumbleweed with KDE Plasma desktop? (Support for legacy tray icons is restored in KDE Workspace 5.4 or 5.5.)
They should work fine in general. But just to be clear here: Plasma5's system tray still doesn't support old- style icons, and never will. A hack named xembedsniproxy has been created that acts as old-style system tray and "converts" old-style icons to the new SNI that are then added to the system tray. It acts as a "proxy" between the application that creates an old- style systray icon and the system tray itself that only supports SNI.
At first I saw this issue using Pidgin 3.0.0 (GTK+3, Pidgin development version). The tray icon is displayed very small and the context menu does not work.
Might be fixed by this upstream commit, which I'm about to add to our package: https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=1a13806d74973137960e64aa347965525a7c626a Old-style icons are drawn by the application, they are actually small application windows that used to get embedded into the system tray (via XEmbed which won't work on Wayland). The system tray has absolutely no control over the icon (that's one of the problems fixed in the "new" SNI specification from 2009). xembedsniproxy tries to resize that window to a reasonable size, but the currently used method apparently doesn't work with GTK+ applications.
The icon is displayed correctly. But the context menu does not work.
That's a different problem, specific to Java applications (but maybe also others). They ignore the fake mouse button events that xembedsniproxy sends them. https://bugs.kde.org/show_bug.cgi?id=358328 With "normal" old-style system tray icons, the application gets the mouse click event directly, in Plasma5 xembedsniproxy creates a new-style icon on the fly, so it gets the event and has to fake a mouse click on the XEmbed window. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Bauer <wbauer@tmo.at> schreef op 29 februari 2016 23:29:02 CET:
Am Montag, 29. Februar 2016, 17:28:54 schrieb Bjoern Voigt:
Could someone confirm, that legacy tray icons do not work as expected in Tumbleweed with KDE Plasma desktop? (Support for legacy tray icons is restored in KDE Workspace 5.4 or 5.5.)
They should work fine in general.
But just to be clear here: Plasma5's system tray still doesn't support old- style icons, and never will. A hack named xembedsniproxy has been created that acts as old-style system tray and "converts" old-style icons to the new SNI that are then added to the system tray. It acts as a "proxy" between the application that creates an old- style systray icon and the system tray itself that only supports SNI.
At first I saw this issue using Pidgin 3.0.0 (GTK+3, Pidgin development version). The tray icon is displayed very small and the context menu does not work.
Might be fixed by this upstream commit, which I'm about to add to our package: https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=1a13806d74973137960e64aa347965525a7c626a
Old-style icons are drawn by the application, they are actually small application windows that used to get embedded into the system tray (via XEmbed which won't work on Wayland). The system tray has absolutely no control over the icon (that's one of the problems fixed in the "new" SNI specification from 2009). xembedsniproxy tries to resize that window to a reasonable size, but the currently used method apparently doesn't work with GTK+ applications.
The icon is displayed correctly. But the context menu does not work.
That's a different problem, specific to Java applications (but maybe also others). They ignore the fake mouse button events that xembedsniproxy sends them. https://bugs.kde.org/show_bug.cgi?id=358328
With "normal" old-style system tray icons, the application gets the mouse click event directly, in Plasma5 xembedsniproxy creates a new-style icon on the fly, so it gets the event and has to fake a mouse click on the XEmbed window.
Kind Regards, Wolfgang
No problems with TW 2016.02.28 ... -- Verstuurd vanaf mijn Android apparaat met Email. Excuseer mijn beknoptheid. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, 1. März 2016, 09:36:26 schrieb dutchgigalo@gmail.com:
No problems with TW 2016.02.28 ...
Yeah, I have no problems either on 13.2 with the latest versions from KDE:Frameworks5. But it depends on what applications you are using. Regarding the upstream patch I mentioned that might fix the tiny icons, you can try the plasma5-workspace package from here: http://download.opensuse.org/repositories/home:/wolfi323:/plasma5-workspace/ Unfortunately it breaks KDE3 applications here (ksensors in particular), their system tray icons are tiny now... :-( Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Bauer wrote:
Am Dienstag, 1. März 2016, 09:36:26 schrieb dutchgigalo@gmail.com:
No problems with TW 2016.02.28 ... Yeah, I have no problems either on 13.2 with the latest versions from KDE:Frameworks5. But it depends on what applications you are using.
Regarding the upstream patch I mentioned that might fix the tiny icons, you can try the plasma5-workspace package from here: http://download.opensuse.org/repositories/home:/wolfi323:/plasma5-workspace/
Unfortunately it breaks KDE3 applications here (ksensors in particular), their system tray icons are tiny now... :-( 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. Pidgin 3.0.0devel's icon is still very tiny.
You cherry-picked something from plasma-workspace (master branch). I tried to compile xembed-sni-proxy directly from master branch. It should be usable without updating the rest of plasma5-workspace. plasma-workspace/xembed-sni-proxy/Readme.md says: "This project should be portable onto all other DEs that speak SNI." But I have a cmake problem: # cd xembed-sni-proxy # mkdir build # cd build # cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr .. [...] CMake Error at CMakeLists.txt:8 (find_package): By not providing "FindXCB.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "XCB", but CMake did not find one. Could not find a package configuration file provided by "XCB" with any of the following names: XCBConfig.cmake xcb-config.cmake Add the installation prefix of "XCB" to CMAKE_PREFIX_PATH or set "XCB_DIR" to a directory containing one of the above files. If "XCB" provides a separate development package or SDK, be sure it has been installed. [...] I found FindXCB.cmake in the net, but not XCBConfig.cmake or xcb-config.cmake. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, 1. März 2016, 21:45:43 schrieb Bjoern Voigt:
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 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.
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.
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. 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 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... Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
Am Donnerstag, 3. März 2016, 23:46:41 schrieben Sie:
Compatibility with KDE3 is not an issue for me.
But for me. And I'm not going to add a patch to our packages that causes such a regression (and it doesn't seem to help in your case anyway). In fact I will even report this problem upstream and hope that commit gets reverted or fixed...
No, this was a misunderstanding. I meant the subdirectory plasma-workspace/xembed-sni-proxy.
Ok.
And if I understood you right, you cherry picked some patches from master branch and you compiled a patched plasma5-workspace package.
Yes.
And I wanted to compile plasma-workspace/xembed-sni-proxy without all the other plasma-workspace directories.
But why? This is basically the same as I packaged. There only have been 3 changes to xembed-sni-proxy in master (compared to 5.5). I backported 2 of them, the 3rd one is about transparency which I'm pretty sure won't help you either.
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)").
As mentioned: zypper wp "cmake(KF5WindowSystem)" This gives: S | Name | Summary | Type --+---------------------+----------------------------------------------+-------- | kwindowsystem-devel | KDE Access to window manager: Build Environm-> | package You can also tell zypper to automatically install all build dependencies of the xembed-sni-proxy source package (I don't think the BuildRequires have changed): zypper si -d xembed-sni-proxy OTOH, you can also get the latest master version of plasma5-workspace from the KDE:Unstable:Frameworks repo. If you don't want to install that (which would be understandable of course ;-) ), you can just extract the xembedsniproxy executable and copy it to your system as I already wrote. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Bauer wrote:
Am Donnerstag, 3. März 2016, 23:46:41 schrieben Sie:
Compatibility with KDE3 is not an issue for me. But for me.
And I'm not going to add a patch to our packages that causes such a regression (and it doesn't seem to help in your case anyway).
In fact I will even report this problem upstream and hope that commit gets reverted or fixed... Yes, good idea.
Personally I think that GTK+ 3 and Java support is important.
And I wanted to compile plasma-workspace/xembed-sni-proxy without all the other plasma-workspace directories. But why? This is basically the same as I packaged.
There only have been 3 changes to xembed-sni-proxy in master (compared to 5.5). I backported 2 of them, the 3rd one is about transparency which I'm pretty sure won't help you either.
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)"). As mentioned: zypper wp "cmake(KF5WindowSystem)" This gives: S | Name | Summary | Type --+---------------------+----------------------------------------------+-------- | kwindowsystem-devel | KDE Access to window manager: Build Environm-> | package
You can also tell zypper to automatically install all build dependencies of the xembed-sni-proxy source package (I don't think the BuildRequires have changed): zypper si -d xembed-sni-proxy
OTOH, you can also get the latest master version of plasma5-workspace from the KDE:Unstable:Frameworks repo. If you don't want to install that (which would be understandable of course ;-) ), you can just extract the xembedsniproxy executable and copy it to your system as I already wrote. Thanks for the hints. I installed all the build-dependencies from xembed-sni-proxy, e.g. like suggested
# zypper wp "cmake(Qt5X11Extras)" Command 'what-provides' is replaced by 'search --provides --match-exact'. See 'help search' for all available options. Loading repository data... Reading installed packages... S | Name | Summary | Type --+--------------------------+--------------------+-------- | libqt5-qtx11extras-devel | Qt Development Kit | package # zypper install libqt5-qtx11extras-devel Anyway, the Git master source for plasma-workspace/xembed-sni-proxy still complains: -- Detecting CXX compile features - done CMake Error at CMakeLists.txt:8 (find_package): By not providing "FindXCB.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "XCB", but CMake did not find one. Could not find a package configuration file provided by "XCB" with any of the following names: XCBConfig.cmake xcb-config.cmake Add the installation prefix of "XCB" to CMAKE_PREFIX_PATH or set "XCB_DIR" to a directory containing one of the above files. If "XCB" provides a separate development package or SDK, be sure it has been installed. I tested xembedsniproxy extracted from http://ftp5.gwdg.de/pub/opensuse/repositories/KDE:/Frameworks5/openSUSE_Fact..., but it also shows the discussed problems (Java tray icons not working, tiny Pidgin 3.0.0 icon). I will probably wait for fixes from the KDE or Pidgin teams. For Pidgin I will probably file a bug report. For KDE I will re-check, if all important details are already reported. Fortunately the Pidgin tray icon is optional and can be disabled in preferences in the meantime. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 4. März 2016, 15:37:04 schrieb Bjoern Voigt:
Personally I think that GTK+ 3 and Java support is important.
Well, it's not a question of "supporting" Java or GTK+3. The point is that someone needs to find out why their system tray icons do not work properly, and then find a workaround that hopefully won't break others. Again, in the end those problems all boil down to the limitations of the old system tray protocol. The system tray has absolutely no control over the icons, they are application windows and the applications can do with them whatever they want (or not). The real fix would be to make Pidgin (or GTK3) and Java support the new style system tray. But, Java icons display completely fine here, with and without the patch. Clicking on them has no effect, but as I wrote already, that's a completely different problem. Haven't tried pidgin 3.0 yet, but 2.8 works fine in all regards.
Anyway, the Git master source for plasma-workspace/xembed-sni-proxy still complains:
-- Detecting CXX compile features - done CMake Error at CMakeLists.txt:8 (find_package): By not providing "FindXCB.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "XCB", but CMake did not find one.
Could not find a package configuration file provided by "XCB" with any of the following names:
XCBConfig.cmake xcb-config.cmake
Add the installation prefix of "XCB" to CMAKE_PREFIX_PATH or set "XCB_DIR" to a directory containing one of the above files. If "XCB" provides a separate development package or SDK, be sure it has been installed.
So it seems you just cannot compile xembed-sni-proxy without the rest. Maybe it needs some cmake files in the upper directories. Might work if you download the whole plasma-workspace source code and don't delete anything but just run cmake inside the plasma-sni-proxy directory. Haven't tried that though.
I tested xembedsniproxy extracted from http://ftp5.gwdg.de/pub/opensuse/repositories/KDE:/Frameworks5/openSUSE_Fac tory/src/xembed-sni-proxy-0.0.1git~20151104~ded1538-12.1.src.rpm, but it also shows the discussed problems (Java tray icons not working, tiny Pidgin 3.0.0 icon).
I thought Pidgin worked before. At least this bug report The mouse clicks *never* worked on Java system tray icons though, yes. And still doesn't in latest master. PS: A workaround would be to disable xembedsniproxy's autostart (or kill it), and run a "real" old-style system tray instead, e.g. icewmtray or wmsystemtray like suggested here: https://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Bauer wrote:
The real fix would be to make Pidgin (or GTK3) and Java support the new style system tray. Yes, but this can take a long long time. Fixing Linux/X11 related bugs doesn't seem to have high priority in the Java Runtime development.
One example: This really annoying bug exists since 2012 and isn't fixed until now: https://bugs.openjdk.java.net/browse/JDK-7172749 That's why I hope, that the KDE team finds a solution before the Java Runtime development team.
But, Java icons display completely fine here, with and without the patch. Clicking on them has no effect, but as I wrote already, that's a completely different problem. I know, but having an icon without a working menu is useless.
Haven't tried pidgin 3.0 yet, but 2.8 works fine in all regards. BTW, Pidgin 2.10.12 is the stable version. Pidgin 2.8 probably has some security related bugs, maybe you have a version with backported fixes. Pidgin 3.0.0devel is only a development version.
Anyway, the Git master source for plasma-workspace/xembed-sni-proxy still complains:
-- Detecting CXX compile features - done CMake Error at CMakeLists.txt:8 (find_package): By not providing "FindXCB.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "XCB", but CMake did not find one.
Could not find a package configuration file provided by "XCB" with any of the following names:
XCBConfig.cmake xcb-config.cmake
Add the installation prefix of "XCB" to CMAKE_PREFIX_PATH or set "XCB_DIR" to a directory containing one of the above files. If "XCB" provides a separate development package or SDK, be sure it has been installed. So it seems you just cannot compile xembed-sni-proxy without the rest. Maybe it needs some cmake files in the upper directories. Might work if you download the whole plasma-workspace source code and don't delete anything but just run cmake inside the plasma-sni-proxy directory. Haven't tried that though. Thanks for the hints. I haven't deleted anything. If I find time, I take a look at the KDE Git repository SPEC file for plasma5-workspace.
I tested xembedsniproxy extracted from http://ftp5.gwdg.de/pub/opensuse/repositories/KDE:/Frameworks5/openSUSE_Fac tory/src/xembed-sni-proxy-0.0.1git~20151104~ded1538-12.1.src.rpm, but it also shows the discussed problems (Java tray icons not working, tiny Pidgin 3.0.0 icon). I thought Pidgin worked before. At least this bug report
The mouse clicks *never* worked on Java system tray icons though, yes. And still doesn't in latest master.
PS: A workaround would be to disable xembedsniproxy's autostart (or kill it), and run a "real" old-style system tray instead, e.g. icewmtray or wmsystemtray like suggested here: https://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ Yes, "icewmtray" works for me. I will probably use it as a workaround.
Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sonntag, 6. März 2016, 14:00:01 schrieb Bjoern Voigt:
That's why I hope, that the KDE team finds a solution before the Java Runtime development team.
I would hope that too, of course.
I know, but having an icon without a working menu is useless.
I basically wanted to say that a "fix" for the one thing (the size) won't help with the other problem (mouse clicks being ignored).
BTW, Pidgin 2.10.12 is the stable version. Pidgin 2.8 probably has some security related bugs, maybe you have a version with backported fixes. Pidgin 3.0.0devel is only a development version.
Actually I did try 2.10.10, i.e. the version included in 13.2. I don't use pidgin at all though, I just installed it to test this (a few weeks ago already), and forgot to check the version number before replying (I somehow had 2.8 in my mind...).
Thanks for the hints. I haven't deleted anything. If I find time, I take a look at the KDE Git repository SPEC file for plasma5-workspace.
I have to admit that I never tried to build plasma-workspace's xembed-sni- proxy alone. The easiest way to get it to build then is probably to start from the (older) stand-alone version, and just replace the source files with the ones from plasma-workspace git master. https://github.com/davidedmundson/xembed-sni-proxy Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/01/2016 09:45 PM, Bjoern Voigt wrote:
Wolfgang Bauer wrote:
Am Dienstag, 1. März 2016, 09:36:26 schrieb dutchgigalo@gmail.com:
No problems with TW 2016.02.28 ... Yeah, I have no problems either on 13.2 with the latest versions from KDE:Frameworks5. But it depends on what applications you are using.
Regarding the upstream patch I mentioned that might fix the tiny icons, you can try the plasma5-workspace package from here: http://download.opensuse.org/repositories/home:/wolfi323:/plasma5-workspace/
Unfortunately it breaks KDE3 applications here (ksensors in particular), their system tray icons are tiny now... :-( 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. Pidgin 3.0.0devel's icon is still very tiny.
You cherry-picked something from plasma-workspace (master branch). I tried to compile xembed-sni-proxy directly from master branch. It should be usable without updating the rest of plasma5-workspace. plasma-workspace/xembed-sni-proxy/Readme.md says:
"This project should be portable onto all other DEs that speak SNI."r Morning all,
I just tried the leap version under enlightenment and hexchat, which gave me a black square in the top left of the screen that I could click on to show / hide hexchat and right clicking was correctly showing the menu. However there was no Icon and the icon also didn't show in the enlightenment sni systray widget. Looking at this further is somewhere lower down on my todo list, as enlightenment upstream is not that interested and almost all applications that I have tried with openSUSE work or have some form of plug-in, Pidgin has atleast one here you could try ( I haven't) https://github.com/philipl/pidgin-indicator . I also backported the nm-applet (NetworkManager-gnome) code for sni into a separate package for enlightenment. As such integrating this with enlightenment would mostly benefit other distro's that haven't pulled in the sni support for Qt4 apps etc. Cheers Simon
But I have a cmake problem:
# cd xembed-sni-proxy # mkdir build # cd build # cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr .. [...] CMake Error at CMakeLists.txt:8 (find_package): By not providing "FindXCB.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "XCB", but CMake did not find one.
Could not find a package configuration file provided by "XCB" with any of the following names:
XCBConfig.cmake xcb-config.cmake
Add the installation prefix of "XCB" to CMAKE_PREFIX_PATH or set "XCB_DIR" to a directory containing one of the above files. If "XCB" provides a separate development package or SDK, be sure it has been installed. [...]
I found FindXCB.cmake in the net, but not XCBConfig.cmake or xcb-config.cmake.
Greetings, Björn
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
dutchgigalo@gmail.com wrote:
No problems with TW 2016.02.28 ... Do you tried a Java and/or a GTK+ 3.x application? These application types are probably affected. Wolfgang Bauer mentioned a bug report about the Java problem.
I have the problem with latest TW with Java application (for example the small example https://docs.oracle.com/javase/tutorial/uiswing/examples/misc/index.html#Tra...) and with Pidgin 3.0.0devel (a GTK+ 3.x application). Pidgin 2.10.x is unaffected, because it is linked against GTK+ 2.x. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Bjoern Voigt -
dutchgigalo＠gmail.com -
Simon Lees -
Wolfgang Bauer