Bug 393787 - Icons only task manager gets confused between Native Steam app and Wine Steam
Summary: Icons only task manager gets confused between Native Steam app and Wine Steam
Alias: None
Product: plasmashell
Classification: Plasma
Component: Icons-only Task Manager (show other bugs)
Version: 5.12.4
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: 1.0
Assignee: Eike Hein
Depends on:
Reported: 2018-05-03 03:22 UTC by Benjamin Xiao
Modified: 2018-06-18 10:20 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:

xprop output for native steam window (6.05 KB, text/plain)
2018-05-04 09:23 UTC, Benjamin Xiao
xprop output for wine steam window (4.24 KB, text/plain)
2018-05-04 09:24 UTC, Benjamin Xiao
xprop of native steam window while bug is occuring (6.05 KB, text/plain)
2018-05-08 04:12 UTC, Benjamin Xiao
Picture of bug (716.83 KB, image/jpeg)
2018-05-08 04:20 UTC, Benjamin Xiao

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Xiao 2018-05-03 03:22:32 UTC
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.
Comment 1 Benjamin Xiao 2018-05-03 03:33:51 UTC
For reference this is Wine Steam's desktop file:

[Desktop Entry]
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
Title: Steam
Machine: <hidden>

Likewise here's native Steam's .desktop file:
[Desktop Entry]
Comment=Application for managing and playing games on Steam
Exec=/usr/bin/steam %U

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

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?
Comment 2 Eike Hein 2018-05-04 01:29:20 UTC
Please post xprop output for the two windows and the .desktop file names too.
Comment 3 Benjamin Xiao 2018-05-04 09:23:46 UTC
Created attachment 112411 [details]
xprop output for native steam window
Comment 4 Benjamin Xiao 2018-05-04 09:24:19 UTC
Created attachment 112412 [details]
xprop output for wine steam window
Comment 5 Benjamin Xiao 2018-05-04 09:26:57 UTC
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.
Comment 6 Benjamin Xiao 2018-05-08 04:12:26 UTC
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.
Comment 7 Benjamin Xiao 2018-05-08 04:20:58 UTC
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.
Comment 8 Benjamin Xiao 2018-05-21 17:41:35 UTC
This is happening quite frequently now. Eike Hein, have you been able to reproduce it on your machine?
Comment 9 Eike Hein 2018-05-22 12:32:43 UTC
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.
Comment 10 Benjamin Xiao 2018-05-23 05:03:01 UTC
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?
Comment 11 Eike Hein 2018-05-23 10:10:55 UTC
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".
Comment 12 Eike Hein 2018-05-23 11:26:54 UTC
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.
Comment 13 Eike Hein 2018-05-23 16:38:45 UTC
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

Subscribers: plasma-devel

Tags: #plasma

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

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

Comment 14 Benjamin Xiao 2018-05-23 17:11:42 UTC
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!
Comment 15 Eike Hein 2018-05-23 17:19:33 UTC
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 ...
Comment 16 Eike Hein 2018-05-23 18:10:14 UTC
And the next part: https://phabricator.kde.org/D13073

Between the two, both Steam versions are now correctly mapped, pin well, etc.
Comment 17 Benjamin Xiao 2018-05-23 18:30:14 UTC
Wonderful! Looking forward to seeing these changes land in the next update. Thanks again for your wonderful work.
Comment 18 Eike Hein 2018-05-23 18:35:28 UTC
No problem, thanks for your bug report and the patience!
Comment 19 Christoph Feck 2018-06-15 21:46:20 UTC
Eike, any more work to do for this ticket after the commit from comment #16?
Comment 20 Eike Hein 2018-06-18 10:20:21 UTC
Nope, it's done. Thx for the poke!