STEPS TO REPRODUCE 1. Install Steam 2. Launch Steam 3. Use Steam to find and install any game (tried with several) 4. When prompted, let it install a desktop shortcut but NOT a start menu shortcut (these are the default options) 4. Launch that game 5. Alt-tab out of the game 6. Right-click on the game's Task Manager entry OBSERVED RESULT The "Pin" menu item is disabled. EXPECTED RESULT The "Pin" menu item should be enabled SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon User Edition KDE Plasma Version: Plasma 5.15.3 KDE Frameworks Version: 5.57 Qt Version: 5.12.1 ADDITIONAL INFORMATION Happens with the Icons-Only Task Manager, too.
If during installation, you do tell Steam to make a start menu shortcut for the game, then the same problem is still seen. Also, the entry created in the menu has no icon. Its context menu does have an enabled "Pin to Task Manager" entry, but clicking it does nothing.
I only have two games, but the WM_CLASS on mine is clearly off. WM_CLASS(STRING) = "Liftoff.x86_64", "Liftoff.x86_64" Can you run "xprop" and click on the window on your game and confirm it's the same pattern of the correct .desktop name followed by ".x86_64" This is going to be an upstream bug, I'll report it.
Actually for the three games I tried, they're different and neither conforms to that pattern. :/ Puzzle Agent: WM_CLASS(STRING) = "grickle102.exe", "Wine" Pillars of Eternity: WM_NAME(STRING) = "Pillars of Eternity" Shadowrun: WM_NAME(STRING) = "Shadowrun" I can test more if you need me to.
Bottom two aren't the WM_CLASS
Urgh, sorry. For Pillars of Eternity and Shadowrun, WM_CLASS actually does not appear in the xprop output, so I blindly pasted WM_NAME, which appears in roughly the same place in the output. Here are two more that do have WM_CLASS defined: Civilization 5: WM_CLASS(STRING) = "Civ5XP", "Civ5XP" Knights of the Old Republic 2: WM_CLASS(STRING) = "KOTOR2", "KOTOR2" None can be pinned.
I just did some investigation, I tried with Half-Life 2 Deathmatch: The process name is hl2_linux. WM_CLASS(STRING) = "hl2_linux", "hl2_linux" The desktop file is named "Half-Life 2 Deathmatch Source.desktop": [Desktop Entry] Name=Half-Life Deathmatch: Source Comment=Play this game on Steam Exec=steam steam://rungameid/360 Icon=steam_icon_360 Terminal=false Type=Application Categories=Game; As you can see it has no StartupWMClass and its Exec line doesn't match the resulting executable commandline at all: /home/kaiuwe/.steam/steam/steamapps/common/Half-Life 1 Source Deathmatch/hl2_linux -game hl1mp -steam There's no information for us to map the hl2_linux back to the .desktop file at all, neither by going via WM_CLASS nor by going via process name.
So is this something that would need to be fixed in Steam, or is there anything we can do on our end?
Given it's not even consistently wrong, this is something that needs to be fixed in every single game that's broken.
If the process name and WM_CLASS match, could we use WM_CLASS as an additional point of comparison beyond StartupWMClass?
Even if WM_CLASS and process name match, that won't help us here since the Exec is steam and not hl2_linux. The string hl2_linux doesn't appear in the .desktop file at all...
> If the process name and WM_CLASS match, could we use WM_CLASS as an additional point of comparison beyond StartupWMClass? You're a bit confused there. We already look at WM_CLASS, process name, all the things - what we compare them to is the .desktop file, and as Kai points out neither WM_CLASS nor process name can be related to the .desktop file.
I see, so the desktop files would all need StartupWMClass entries that match either WM_CLASS or the executable name?
Still reproducible here.