Task manager (as well as Icon only task manager) always shows Hangouts with the generic Chrome icon. I tried adding the following rule for Chrome in /etc/xdg/taskmanagerrulesrc: [Rewrite Rules][Google-chrome][1] Property=ClassName Identifier=StartupWMClass Match=(?<=crx_)(?'match'[a-z]+) Target=chrome-%1-default I also have the following desktop file in .local/share/applications/, named chrome-nckgahadagoaajjgafhacjanaoiihapd-default.desktop: [Desktop Entry] Version=1.0 Terminal=false Type=Application Name=Google Hangouts Icon=chrome-nckgahadagoaajjgafhacjanaoiihapd-default NoDisplay=true Exec=/opt/google/chrome/chrome StartupWMClass=crx_nckgahadagoaajjgafhacjanaoiihapd The icons are in: .local/share/icons/hicolor/128x128/apps/chrome-nckgahadagoaajjgafhacjanaoiihapd-default.png .local/share/icons/hicolor/48x48/apps/chrome-nckgahadagoaajjgafhacjanaoiihapd-default.png And yet, both task managers always show the generic Chrome icon. If I set the NoDisplay property to false, I can see the launcher in the application menu (under the Lost&Found section) with the correct Hangouts icon.
Created attachment 116305 [details] Patch Matching xWindowsWMClassName before appId fixes it for me. No need for rules in taskmanagerrulesrc either.
Kai: As the resident Chrome guy, can you look into this?
The problem is that google-chrome.desktop as shipped has StartupWMClass=Google-chrome, so all Chrome windows always match on appId (i.e. XClassHint::res_class). xWindowsWMClassName (XClassHint::res_name) and rewrite rules are never even evaluated. Shouldn't the xWindowsWMClassName be evaluated first, since it is more specific?
The idea is to identify applications, and the application id is what the second string in WM_CLASS (i.e. the "class" in ICCCM parlance) corresponds to. If this is to be Hangouts and not Google Chrome, then it should say so in that part of WM_CLASS. This is an opinionated take based on what most apps on the platform actually do - as in, if we change the order other things will break instead since a lot of apps end up putting random crap into the instance part of WM_CLASS. I've even seen window titles in there, and then your taskbar ends up resorting based on the website you're viewing, ... there's never an easy victory. Chrome (and Chrome web apps in particular) is an app we end up somehow fixing at least once a year when they pull some new random foolhardery - it's high in my personal charts for most ill-behaved Linux desktop app. The rewrite rules can swap instance for class, though, iirc.
Okay, I added: Google-chrome::crx_nckgahadagoaajjgafhacjanaoiihapd=chrome-nckgahadagoaajjgafhacjanaoiihapd-default.desktop to the mapping section of taskmanagerrulesrc. This works, but now the taskbar ignores the icon set in the .desktop file and uses the one it pulled from the _NET_WM_ICON atom, which is unfortunately only 16x16 in size.
Oh, I see, it wants file:// + the absolute path to the .desktop file. Working fine now. Thanks for your support.
Looks like an old issue. Setting it to needs more info. Please try with a newer version(plasma 5.23.5) and if this is not an issue any more let us know.Bugs placed into NEEDSINFO status will receive a reminder if the ticket: Is at least 15 days old Has not received any comment within 15 days If a bug remains in NEEDSINFO for another 15 days with no comment, it will be closed as RESOLVED > WORKSFORME.
Still present on 5.23.90. Let me know what further info is needed.
Fixed in 5.27