Bug 393787

For reference this is Wine Steam's desktop file:

[Desktop Entry]
Name=Steam
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
Type=Application
StartupNotify=true
Path=/home/benxiao/.wine/dosdevices/c:/Program Files (x86)/Steam
Icon=10B4_steam.0
StartupWMClass=steam.exe

Here's the info from Window Rules for Wine Steam:
Class: Wine (steam.exe Wine)
Role:
Type: Normal Window
Title: Steam
Machine: <hidden>



Likewise here's native Steam's .desktop file:
[Desktop Entry]
Name=Steam
Comment=Application for managing and playing games on Steam
Exec=/usr/bin/steam %U
Icon=steam
Terminal=false
Type=Application
Categories=Network;FileTransfer;Game;
MimeType=x-scheme-handler/steam;
Actions=Store;Community;Library;Servers;Screenshots;News;Settings;BigPicture;Friends;

And native Steam's window info:
Class: Steam (Steam Steam)
Role:
Type: Unknown - will be treated as Normal Window
Title: Steam
Machine:


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:

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".

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:

https://phabricator.kde.org/D13058

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.

Summary:
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

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D13058

M  +0    -1    libtaskmanager/taskmanagerrulesrc
M  +2    -2    libtaskmanager/tasktools.cpp

https://commits.kde.org/plasma-workspace/30654e2158c454de664d54073544ae2ca295ce2f

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!