https://bugs.kde.org/show_bug.cgi?id=393787
--- Comment #11 from Eike Hein <h...@kde.org> --- I had a look at this today, and it seems it's a weird recent behavior change in Wine. Background: Some time last year we improved our StartupWMClass handling in Plasma. I also engaged the Wine guys and got them to generate StartupWMClass keys in their .desktop files: https://bugs.winehq.org/show_bug.cgi?id=32699 So now I installed Steam on wine, and sure enough the .desktop file for Steam has StartupWMClass=steam.exe in it. Great. Here's where it breaks down: WM_CLASS is two strings, specified as being the "Instance" and "Class". This is meant to be able to differentiate e.g. between different windows (instances) belonging to the same app (class). For the purposes of app identification, Plasma (and other DEs) only really look at the Class string and match it up to .desktop file names or StartupWMClass keys. I'm pretty sure Wine used to put the .exe name as the WM_CLASS Class, but on my system, for the Steam window, the WM_CLASS is now also: WM_CLASS(STRING) = "steam.exe", "Wine" So it's using Wine as Class string, and the .exe as Instance string. Now we need to decide how to handle this, especially in a way that's unlikely to break if Wine changes behavior again in the future. The most likely way will be that I'll add a new rule to our taskmanagerrulesrc file (where hack-around rules can be placed) that maps swaps Instance and Class when the Instance matches "Wine". -- You are receiving this mail because: You are watching all bug changes.
