https://bugs.kde.org/show_bug.cgi?id=396843
--- Comment #8 from Michail Vourlakos <mvourla...@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
