Created attachment 114111 [details] Screenshot of fullscreen task manager applet GIMP 2.10 is probably the best (worst) example of this. Plasma's task managers use GIMP's (hardcoded?) gray pixelated icon at all times instead of the icon present in the Breeze icon pack. This is most noticeable with latte-dock, where the icons are pretty large (latte-dock uses libtaskmanager to load app icons). Similar behavior can be seen with JetBrains tools, such as IntelliJ IDEA. They use their custom icons (not icons from an icon pack) in their .desktop files. In addition, JetBrains Toolbox (a tool for downloading and installing JetBrains applications), enforces these .desktop files to look a certain way - they point to specific .svg files in specific directories to retrieve their icons. If you open up an app launcher applet in KDE Plasma, JetBrains applications do not have icons shown at all. Unless you start typing their names, that is: then they do have icons (What??). In latte-dock, their icons are pixelated, unless the apps are open. My proposed solution is to give the end-user an option in settings to make task managers always use icons from icon packs or from .desktop files. An even better solution is to check whether the icon that the application provides is large enough - if not, default to the icon pack/.desktop file.
Created attachment 114112 [details] Screenshot of latte-dock with GIMP
It will use the icon from the icon theme if it can map the application to its desktop file. Can you provide the output of xprop for the Gimp window and tell us the name of its .desktop file and its contents?
Works for me with the standard Task Manager or the alternative Icons-Only Task Manager, FWIW: GIMP gets the nice themed icon, not the horrible pixelly window icon. This seems like a latte-dock bug. Also, please provide the information that Kai requested so we can proceed here.
Also, the issue with the JetBrains apps' icons is something separate, most likely Bug 394981
(In reply to Nate Graham from comment #3) > FWIW: GIMP gets the nice themed icon, not the horrible pixelly > window icon. This seems like a latte-dock bug. > This has nothing to do with Latte... There are plenty of broken desktop files that miss StartupWMClass which is the only way for plasma libtaskmanager to associate Windows with Launchers if the desktop file name doesnt much the StartupWMClass. I had the same issue in TumbleWeed, I had to add at gimp.desktop file: StartupWMClass=gimp-2.10 as it appears in new gimp version the StartupWMClass changed from gimp to gimp-2.10 More info to help users: https://github.com/psifidotos/Latte-Dock/wiki/F.A.Q.#q-after-the-launcher-bouncing-animation-the-window-showing-isnt-smooth
Ah, thanks for the info, Michail! So is this a GIMP regression that we should report to them, and in the meantime do we need another special case for it?
The JetBrains apps are known to be buggy and set incorrect window meta data. We get reports about this regularly and encourage users to report it upstream. We've been told they have but upstream seems uninterested in the issue. About Gimp, it should work fine - if it doesn't work on your system, please upload the following information: 1. the name and contents of the gimp .desktop file on your system 2. xprop output for the gimp window
(In reply to Nate Graham from comment #6) > Ah, thanks for the info, Michail! So is this a GIMP regression that we > should report to them ? let me describe you first the situation and in the end lets see what can be done from all parts? :) > in the meantime do we need another special case for it? I am not that much of the special cases but rather plasma team to be informed first on the situation and then forward upstream what needs to be forwarded... 1. First it is the desktop file specification: https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html you can read there that StartupWMClass is not required 2. Plasma main libtaskmanager developers (Kai and Eike) had to solve a question. How to associate taskmanager entries with desktop files and windows? There are discussions that this isnt as easy as someone might guess... So libtaskmanager developers have decided how smart can plasma libtaskmanager be and anything above that limit it is an upstream issue. Application developers should take responsibility of their apps and improve their metadata at desktop files. Personally I think that [2] approach is correct. My guess is that DEs that dont show such issues just make their taskmanagers too smart to identify desktop files and windows and this leads in a situation that the desktop file metadata are never updated correctly upstream. ---- This issue can be noticed in plasma in two ways: 1. the icons are pixelated in plasma taskmanager and not using the icon theme to render 2. some launchers instead of grouped with their windows in the icon-only taskmanager they show a different record at the end of the taskmanager ---- Current plasma libtaskmanager smartness threshold: Current Situation: A. Window provided WM_CLASS matches the desktop filename e.g. : blender.desktop (xprop): WM_CLASS(STRING) = "blender" (StartupWMClass isnt needed) B. Accept the new standard for desktop files naming e.g. : org.kde.dolphin.desktop (xprop): WM_CLASS(STRING) = "dolphin" (StartupWMClass isnt needed) C. Use the StartupWMClass record from desktop file to check the WM_CLASS record (the gimp mentioned case): gimp.desktop StartWMClass=gimp-2.10 (this was missing in user's system) (xprop): WM_CLASS(STRING) = "gimp-2.10" D. The LibreOffice 6 case :) I still can not identify what breaks, it appears double records. Adding StartupWMClass isnt fixing it. ---- Should plasma team increase the smartness threshold? I really dont know :) this is for Kai and Eike to answer.
Generally speaking, we try to set our "smartness threshold" at maximum and I'm actually quite confident that libtaskmanager is currently the best implementation of this stuff on the Linux desktop - I know quite a few complicated cases that competing implementations such as Canonical's bamf and Gnome Shell's window tracker fail to handle correctly, but work just fine in Plasma. I'm not aware of any open bugs with LO6 anymore, but I might be forgetting something. As for the whole "My proposed solution is to give the end-user an option in settings to make task managers always use icons from icon packs or from .desktop files" - we're not going to add a GUI way to do this, but note there's taskmanagerrulesrc, which supports extensive rewrite rules to work around plain-broken apps (and we do ship some pragmatic workarounds). Rather than add GUI we should just document that better. But generally it's always better to get upstream to fix things than go for the workaround.
Thanks for the background, everyone! Very enlightening. So what do we do here? Mark this as DOWNSTREAM and file a bug with the GIMP folks?
I see that for GIMP, we already have an exception in taskmanagerrulesrc for the 2.8 release: [Mapping] Gimp-2.8=GIMP Perhaps we just need to do the same for the 2.10 release. :(
^ Probably
Jan, does it solve the GIMP issue if you open /etc/xdg/taskmanagerrulesrc and add "gimp-2.10=gimp" on its own line under the "[Mapping]" header?
I apologize for being unresponsive for the last couple of days. I was not expecting you to respond in such a quick and serious manner and I'm pleasantly surprised that you did! I guess I'm too used to proprietary software support being oblivious to my issues and therefore I tend to forget how awesome the FOSS community is. Modifying taskmanagerrulesrc did not work for me, I don't know why. I even tried `gimp-2.10=GNU Image Manipulation Program`, to no avail. I'd also like to add that my gimp.desktop file does not contain any StartupWMClass entry by default at all. I'm on Manjaro Linux - Arch based. The xprop output is included in an attachment. However, the temporary fix suggested by Michail (adding `StartupWMClass=gimp-2.10` to gimp.desktop) did work. Btw, thanks for pointing me to an existing issue regarding JetBrains applications. Also, thanks for explaining how libtaskmanager operates. I was unaware of both taskmanagerrulesrc and StartupWMClass up until now.
Created attachment 114160 [details] GIMP window xprop
Created attachment 114161 [details] gimp.desktop (containing appropriate StartupWMClass which fixes the issue)
Fixed with the fix for Bug 396871. *** This bug has been marked as a duplicate of bug 396871 ***