SUMMARY kwin can't read WM_CLASS of a specific application (bitwig studio), even though xprop can. Because of this, i have to use the window title to create an application rule, which could potentially break. STEPS TO REPRODUCE 1. install bitwig studio and launch the application in demo or guest mode 2. open system settings and navigate to Window Management -> Window Rules -> New -> Detect Window Properties and click the bitwig studio window. 3. open a terminal, run xprop and click the bitwig studio window OBSERVED RESULT xprop correctly shows "WM_CLASS(STRING) = 'com.bitwig.BitwigStudio'", which is exactly what is specified in the .dekstop file. kwin however returns "()" as window class. EXPECTED RESULT kwin should be able to read the WM_CLASS just like xprop SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 20.04.2 LTS (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION 1. The Bitwig GUI is written in Java as far as i know, and the window also has no title bar. 2. Im new to KDE and Linux in general as well as bug reporting so please excuse me if this has been fixed. I searched for a bit but i couldn't find a similar issue. Im on Kubuntu 20.04.2 LTS, which means that kwin is stuck in version 5.18.5. No idea if this has been fixed since.
Window rules have changed a lot since Plasma 5.18. Any chance you can try again with 5.22? Kubuntu 21.04 with the backports PPA should have it.
I just upgraded to 5.22 using the backport PPA but the issue still persists. The exact version numbers in the system settings are now: KDE Plasma Version 5.22.4 KDE Frameworks Version 5.85.0 Qt Version 5.15.2 Kernel Version 5.11.0-31-generic (64-bit) Graphics Platform X11 kwin -v also reports 5.22.4
Should i update the kwin version in the initial bug report or is it fine to leave it for now?
Darn, thanks for checking. We can update the version.
Can reproduce. The information we retrieve from the window has in fact the relevant fields empty: > qdbus org.kde.KWin /KWin org.kde.KWin.queryWindowInfo caption: Bitwig Studio - New 1 clientMachine: localhost resourceClass: resourceName: . . . Investigating into the issue, while xprop reports a string for WM_CLASS, the application is not fully following the X.org specification, as `WM_CLASS` should have two null-terminated strings, instead of just one, the `instance` and the `class` (excerpt of the spec here: https://unix.stackexchange.com/questions/494169/wm-class-vs-wm-instance). This is probably what's causing the issue. I haven't still find where the information is loaded to see if we could maybe use that single string. It also happens on Wayland session, since it loads via XWayland.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/32
Wow, thanks for following up on this so fast :) I just wrote a mail to Bitwig's support, describing the issue to them and linking the specification. Please hit me up if there's anything else I can do or test.
I've shortly read the conversation you had over at the merge request. While you could argue that it is Bitwigs fault in this case, I would also argue that its possible to read the data correctly, as xprop shows. So why wouldn't we include this fallback? It would definitively be helpful with future applications that fail to meet spec. Just my two cents.
Git commit 8bba48ba30009713f54990d880a4e0e4513386a4 by Nate Graham, on behalf of Ismael Asensio. Committed on 27/08/2021 at 16:22. Pushed by ngraham into branch 'master'. Read uncomplete WM_CLASS string While X.org spec tells that WM_CLASS must contain two null-terminated strings (the instance and the class), some thrid party applications may not fully comply with this. In that case, use the single string provided for both fields: `resourceName` and `resourceClass`, instead of leaving them empty. Those fields having the same string is fairly common also on well-behaved apps. M +3 -0 src/platforms/xcb/netwm.cpp https://invent.kde.org/frameworks/kwindowsystem/commit/8bba48ba30009713f54990d880a4e0e4513386a4
Thank you very much <3