I have Steam installed natively on my Fedora 27 KDE system as well as Steam installed via Wine. Both will create desktop shortcuts. However, now whenever I launch native Steam, the icons only task manager thinks the application is Wine Steam and will use the wrong icon.
This does not happen in GNOME or Unity.
I can work around this by setting StartupWMClass to Steam for the native Steam .desktop file, but this gets overriden every time Steam updates.
Seems like there needs to be more logic to the mapping to be able to differentiate the two apps.
For reference this is Wine Steam's desktop file:
Exec=env WINEPREFIX="/home/benxiao/.wine" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/benxiao/.wine/dosdevices/c:/ProgramData/Microsoft/Windows/Start\\ Menu/Programs/Steam/Steam.lnk
Path=/home/benxiao/.wine/dosdevices/c:/Program Files (x86)/Steam
Here's the info from Window Rules for Wine Steam:
Class: Wine (steam.exe Wine)
Type: Normal Window
Likewise here's native Steam's .desktop file:
Comment=Application for managing and playing games on Steam
And native Steam's window info:
Class: Steam (Steam Steam)
Type: Unknown - will be treated as Normal Window
What I am a bit confused over is why native Steam would match with Wine Steam's .desktop file when it specifies StartupWMClass=steam.exe?
Please post xprop output for the two windows and the .desktop file names too.
Created attachment 112411 [details]
xprop output for native steam window
Created attachment 112412 [details]
xprop output for wine steam window
Wine steam desktop file: Steam.desktop
Native steam desktop file: steam.desktop
Oddly enough, today I can't seem to reproduce the issue though. I've even rebooted several times to see if I could get it to appear again, but so far no luck. Not sure what changed.
Created attachment 112493 [details]
xprop of native steam window while bug is occuring
The bug happened again today. I am still not sure what triggers it. I've uploaded a new xprop output for the Native Steam window, but doing a diff I don't think much has changed.
Created attachment 112494 [details]
Picture of bug
Here's a shot of my desktop showing the issue. I launched native Steam, yet the Wine steam icon shows up instead of simply matching with the pinned native Steam icon.
This is happening quite frequently now. Eike Hein, have you been able to reproduce it on your machine?
I haven't had time yet due to other commitments, sorry. I'll have a look this week. But to be honest, I'm not _super_ optimistic it will be easy.
Thanks for looking into it Eike. You mention that it might be hard to fix, do you have a hint of what could be happening?
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:
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".
Good news - upon further examination, the code we have in place is already flexible enough to handle this Wine behavior as-is. What's preventing things from working is actually a now-obsolete entry in the aforementioned rules file that put Wine in a special code path. All it takes is removing that:
This should go into Plasma 5.12.x and the upcoming 5.13 soon. Ahead of that, you can just find taskmanagerrulesrc on your system (should be in /etc/xdg) and kill the ManualOnly= line.
Git commit 30654e2158c454de664d54073544ae2ca295ce2f by Eike Hein.
Committed on 23/05/2018 at 11:40.
Pushed by hein into branch 'Plasma/5.12'.
Remove legacy Wine hack-around from rules rc.
After we improved our StartupWMClass handling we worked with Wine
in https://bugs.winehq.org/show_bug.cgi?id=32699 to get them to add
StartupWMClass=foo.exe keys to the .desktop files they generate,
since they have foo.exe in WM_CLASS.
This old rule short-circuits the StartupWMClass handling prevented
this from actually working on our side.
Reviewers: broulik, davidedmundson
Differential Revision: https://phabricator.kde.org/D13058
M +0 -1 libtaskmanager/taskmanagerrulesrc
M +2 -2 libtaskmanager/tasktools.cpp
Thanks for the fix Eike!
So this Wine rule in taskmanagerrulesrc was causing native Steam windows to match with the Wine icon? Interesting!
I'll go ahead and remove the ManualOnly=Wine line from taskmanagerrulesrc and give that a test!
No, it's not fully done yet sadly. This change was on the wine side of things so far, making sure the Wine Steam is recognized correctly. There's still problems with keeping the two distinct, because of the duplicate .desktop file names. I need to think of something else for that. But we're getting there ...
And the next part: https://phabricator.kde.org/D13073
Between the two, both Steam versions are now correctly mapped, pin well, etc.
Wonderful! Looking forward to seeing these changes land in the next update. Thanks again for your wonderful work.
No problem, thanks for your bug report and the patience!
Eike, any more work to do for this ticket after the commit from comment #16?
Nope, it's done. Thx for the poke!