I'm not aware of the exact specifics of the icon launcher system i'm afraid.
It may be that supporting Wine may require specific code to handle it's use case...

Under System Settings – Window Behavior, there are these two items: KWin Scripts and Window Rules. With both it is possible to change the behaviour for specific program windows and how they are treated by KWin.

I’m definitely not an expert, but wouldn’t it be possible to use these two existing features to make the wine application appear as the actual linked application (the one with .exe, and with the icon from the link it was invoked with) instead of being treated as the wine application itself?

If this could be fixed by a script or rule, the main KWin application wouldn’t have to “learn” special treatment for wine exclusively and this should be favorized. Only, I wouldn’t know how to do it and, which is the prerequisite: if it is possible at all.

"No"

KWin rules exist to workaround bogus clients, certainly not to alter their identification (what is supposed to be done by the client ONLY and ever - in doubt wine could just immediately "fix" that back)

Checking notepad.exe, wine apparently sets the ClassName to the binary (notepad.exe) while the ClassClass is Wine
-> the solution in this case would be for the taskbar to judge by ClassName instead of ClassClass

luebking wrote:Checking notepad.exe, wine apparently sets the ClassName to the binary (notepad.exe) while the ClassClass is Wine
-> the solution in this case would be for the taskbar to judge by ClassName instead of ClassClass

i tried ClassName but i lost icons. only ClassClass work for icons. but it was grouping still.

What do you mean "lost icons"?
Getting the "unknown" icon? That would probably happen because the classClass will usually be closer to the binary (which is "wine" in your case! the .exe is just loaded binary data)

This is however sth. the taskbar dev needs to care about (ie. try className first and ClassClass as fallback, only group by ClassName, though) - no idea what you can configure as user but that's likely insufficient.

I’m not using wine too much at the moment, and I always use a .desktop link that invokes wine and the actual .exe as (one of) its parameter(s).

Question: what happens if binfmt is used? This would allow to start the .exe directly – and the binfmt kernel extension will then load wine. The same should be true for other interpreter formats, such as .jar for Java, .exe for Mono (a conflict with wine, see https://bugzilla.redhat.com/show_bug.cgi?id=517873).

nothing, wine s still the running process and most importantly will very much likely set "wine" as ClassClass.

I’ve filed a bug for this:
https://bugs.kde.org/show_bug.cgi?id=317264