Closed BlueManCZ closed 3 years ago
Not sure if you're aware of the response but on the latte tracker there was a response to report that to the plasma tracker instead since it's their bug, not latte's. https://invent.kde.org/plasma/latte-dock/-/issues/31#note_170591
Hello. Yes, I filled bug in KDE tracker and also got a response. But to be honest I don't really understand it. https://bugs.kde.org/show_bug.cgi?id=431821
Hello @Kaperios, I finally found a solution to this. I can tell you, get some useful documentation for this is really almost impossible. But here we are. Can you confirm it actually works for you as well, so we can close this?
I switched from xprop
to xdotool
so make sure you have xdotool installed.
Sorry for making you wait so long, didn't notice the e-mail notification. It does seem to work for everything I tested (About 5 Source engine games and 3 GoldSrc ones) but the base half-life and half-life 2.
Thank you, no worries. It works for me in Latte dock as well, so it's resolved.
WM_CLASS is used to connect running applications with existing .desktop files containing application icons.
There are currently two types of games. Games that have WM_CLASS window property already set from the start and games that don't. If they don't, it's usually the fault of game developers and I've been thinking for a long time how to workaround this.
I came up with the script fix-wm-class.sh that can be automatically executed from the game launch options and this script finds window by WM_NAME and sets WM_CLASS to the same value.
This works fine with docks as Dash to Dock or Plank. But we have encountered problems with default KDE panel and Latte dock. (https://github.com/BlueManCZ/SIF/issues/10)
I think these problems are connected with some kind of dynamic WM_CLASS fetching or something similar.