The icons-only task manager does not appear to honour the StartupWMClass in a .desktop spec file. Example: Chrome/Chromium app with .desktop file Expected behaviour: When launching the Chrome app, the active window should be associated with it's own 'icon'. This is the behaviour in the Gnome dock and other docks such as Plank. Actual behaviour: When launching the Chrome app, the app icon 'disappears' immediately and it is grouped with other Chrome windows.
Don't tell me Chrome *yet again* changed their window classes? We do have some mapping rules to match chrome/chromium app windows to their desktop file so they should be treated separately from actual chrome browser windows. What chrome/chromium version is this? Can you provide your desktop file for your app and it's name (e.g. Default-blabla-chrome.desktop) as well as the output of xprop for the respective window (run xprop from terminal and click the Chromium app window).
Changing status to reflect Kai's comment.
Created attachment 104123 [details] Google Photos app .desktop file
Created attachment 104124 [details] Google Photos app xprop output
Ah, you're using profiles, we only matched for -Default but not -Profile_n. Thanks.
$ chromium --version Chromium 56.0.2924.87 I've attached the requested files (.desktop file and xprop output). I was doing some more testing, and created a shortcut for youtube which _does_ work as expected - but others don't. Desktop files are identical apart from the name. Interesting problem...
Ahh, profiles! That explains why my YouTube shortcut worked as expected -- I created it using the 'Default' profile.
I'll have a look, thanks a lot for providing the needed data!
Thanks for looking into it!
Patch under review: https://phabricator.kde.org/D4680 (if you can, please give it a try)
Git commit 513ad12b76a96d2919e1bbfae1c64ba9cfe72770 by Kai Uwe Broulik. Committed on 20/02/2017 at 13:16. Pushed by broulik into branch 'Plasma/5.9'. Map StartupWMClass for Chrome apps instead of RegExp'ing the name We only matched for the "Default" suffix which is the default profile but this breaks when having apps installed in different profiles where they get e.g. "Profile_1" suffix. FIXED-IN: 5.9.3 Differential Revision: https://phabricator.kde.org/D4680 M +5 -10 libtaskmanager/taskmanagerrulesrc M +5 -1 libtaskmanager/xwindowtasksmodel.cpp https://commits.kde.org/plasma-workspace/513ad12b76a96d2919e1bbfae1c64ba9cfe72770
Thanks for getting onto this so quickly. I'm very impressed by this experience. It's been a very long time since I applied a patch and would take me some time to work through -- It may not be something I get to for another few days. Just glancing over the differences makes sense to me, though it concerns me that the rewrite is tied to matching 'crx_'. While this should fix actual Chrome apps, I also have a custom Desktop file I use to start up a local instance of Plex which simply runs Chromium with the --app flag and a local HTTP address. I'll attach the desktop entry as an example. I obtained the string for the StartupWMClass by running xprop on the window. Launching this desktop entry in Gnome has the same behaviour as a Chrome app (ie. it does not group with other Chromium windows, rather it keeps it's own custom icon). I presume that your patch would not cater for this scenario.
Created attachment 104149 [details] Custom Plex Desktop Entry
Just as a final addendum: I'm probably way off the mark here, but the logic that would make most sense to me is, If the StartupWMClass != 'chromium' then do not group with chromium.
I'm working up an overhaul of StartupWMClass handling. The current behavior is written to match real world app behavior in the past, but tides have shifted and now we end up working around the code with mapping rules too often, so it probably makes sense to change the code and test it for a while in master to see what apps break (such is the sad reality of Task Manager development on X11 :).
Patch to overhaul StartupWMClass handling: https://phabricator.kde.org/D4706 This drops all the Chrome-related mapping rules in the process.
Above patch merged.
Perfect! Thanks!
Happy to help, thanks for the report!