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.

Reply via email to