https://bugs.kde.org/show_bug.cgi?id=431821
Fushan Wen changed:
What|Removed |Added
Resolution|--- |INTENTIONAL
CC|
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #13 from Ivo Šmerek ---
Alright, I managed to get this working. It is related to the fact, that
WM_CLASS property has two variables. Look at these two following commands.
Command 1:
> xprop -name "Talos - Linux - 64bit" -f WM_CLASS 8s
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #12 from Ivo Šmerek ---
I recorded a short video to demonstrate what I'm talking about.
https://youtu.be/RxoQ3G_kexM
Excuse the Czech locale.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #11 from Ivo Šmerek ---
And I can confirm that WM_CLASS is changed, appropriate .desktop file with the
StartupWMClass created. But KDE task manager seems to completely disregard
this.
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #10 from Ivo Šmerek ---
I tested it and it does nothing. I tried _NET_WM_ICON_NAME and WM_ICON_NAME.
Games often provide some default icon that I don't see in any property listed
by xprop and this default icon is displayed in task manager
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #9 from David Redondo ---
If you just want it for the icon, could just setting _NET_WM_ICON_NAME work?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #8 from Ivo Šmerek ---
Oh, I just realized that Team Fortess 2 has WM_CLASS from start, but in this
case, it must be changed to distinguish it from other games in the source
engine. All these games have the same WM_CLASS. (Half-Life 2,
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #7 from Ivo Šmerek ---
When is this `windowChanged` method called?
All examples/test cases I know are Steam games. For example, all games listed
in this JSON attribute have WM_CLASS missing. All those games have WM_NAME
property though.
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #6 from David Redondo ---
I took a look at the taskmanager code and actually it seems we support changing
WM_CLASS
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/libtaskmanager/xwindowtasksmodel.cpp#L327
However the way we
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #5 from Ivo Šmerek ---
I tried to change WM_CLASS and then WM_STATE property of the window with xprop
to Withdrawn and back to Normal.
To Withdrawn:
> xprop -f WM_STATE 32ih -set WM_STATE "0,0"
To Normal:
> xprop -f WM_STATE 32ih -set
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #4 from Ivo Šmerek ---
I understand, but I'm looking for a way how to add a WM_CLASS to the window,
which has this property missing from the start. I guess I can't force a window
to go to the withdrawn state and back?
As I said, this xprop
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #3 from David Redondo ---
If I read the spec correctly the window manager can assume that WM_CLASS of a
window basically never changes once it is mapped. So I assume that when you use
xprop it is to late because the window is mapped. See
https://bugs.kde.org/show_bug.cgi?id=431821
--- Comment #2 from iv...@centrum.cz ---
(In reply to David Redondo from comment #1)
> Documentation of WM_CLASS says:
>
> > This property must be present when the window leaves the Withdrawn state
> > and may be changed only while the window is in
https://bugs.kde.org/show_bug.cgi?id=431821
David Redondo changed:
What|Removed |Added
CC||k...@david-redondo.de
--- Comment #1 from
14 matches
Mail list logo
