So, the advice on the KDE mailing list is incorrect. libtaskmanager uses KWindowSystem::icon to get the icon of the window. There are some code paths which fallback to the xorg icon, however when I run wesnoth or instead I also get the generic xorg icon in the window titlebar. So seems to be something deeper in KWindowSystem.

Perhaps Martin can weigh in on this ...

Next fail stage would be in KXUtils::createPixmapFromHandle()  - is it evetually called off the GUI thread?

Well it's SDL - what do you expect? SDL has unfortunately a huge track record of doing things wrongly concerning X11. They clearly beat Firefox in that regard and that means something.

EWMH is quite clear on how the _NET_WM_ICON property has to look like [1]:

_NET_WM_ICON CARDINAL[][2+n]/32

> This is an array of possible icons for the client. This specification does not stipulate what size 
> these icons should be, but individual desktop environments or toolkits may do so. The 
> Window Manager MAY scale any of these icons to an appropriate size.
> 
> This is an array of 32bit packed CARDINAL ARGB with high byte being A, low byte being B. The 
> first two cardinals are width, height. Data is in rows, left to right and top to bottom.

This property has already been specified in version 1.0 of EWMH given the change section. With other words: SDL was not able to implement this in more than a decade. I don't think there is any reason to have any other non-standard way supported in KDE.

[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idp6344560

it's not that simple.
yes, sdl is "slightly" behind, but they support a valid property and since it's correctly resolved inside kwin, apparently the property value is correct as well.

since aaron cofirms the issue with the present taskbar code, which calls the simple function, thus by all possibly required flags, this would mean unenabled multithreaded X11 usage or pot. a clash or bug in the color conversion.

what happens if plasma is running 24bit?

XLIB_SKIP_ARGB_VISUALS=1 plasma-desktop

(In reply to comment #4)
> it's not that simple.
> yes, sdl is "slightly" behind, but they support a valid property and since
> it's correctly resolved inside kwin, apparently the property value is
> correct as well.
> 
> since aaron cofirms the issue with the present taskbar code, which calls the
> simple function, thus by all possibly required flags, this would mean
> unenabled multithreaded X11 usage or pot. a clash or bug in the color
> conversion.
> 
> what happens if plasma is running 24bit?
> 
> XLIB_SKIP_ARGB_VISUALS=1 plasma-desktop

Thomas,

I've tried to run plasma with 24bit support this way:

kquitapp plasma-desktop; sleep 5; XLIB_SKIP_ARGB_VISUALS=1 plasma-desktop

But nothing changed, I still don't see correct icon for "instead" and "wesnoth".

(In reply to comment #5)

> I've tried to run plasma with 24bit support this way:
Seems a great excuse to install scummvm. Reporting back next year or so ;-)

Created attachment 80565 [details]
Simple tool to save an X11 pixmap from the server

Ok?
At least the scummvm icon is fine here (in the plasma taskbar)

64bit architecture? (the id is only 32bit - could be some wrong alignment?)

Attached is a simplistic tool to store the pixmap as png, run

    ./qxpixdownload "0x460000e"

ie. w/ the hexadecimal number you printed with xprop
(g++ call on top of the source)

Can you ensure the pixmap on the server is not the "X11" default but some "real" one?

> Can you ensure the pixmap on the server is not the "X11" default but some "real" one?

I've checked next applications with your tool:
- scummvm
- wesnoth
- instead

And for all of them I see correct icon and mask pictures (not X11 default icon).

> 64bit architecture? (the id is only 32bit - could be some wrong alignment?)

I've dig it for you. See:

1. In Xlib sources:
        in src/Xatomtype.h file:
              in struct xPropWMHints we see such a line:
                    RESOURCEID iconPixmap;

    where RECOURCEID is defined as unsigned long

2. In X11-utils sources, in xprop.c file:
   - bitmap id (to use for icon) -- we see it here:

      #define WM_HINTS_DFORMAT	":\n"\
     "?m2(\t\tbitmap id # to use for icon: $3\n)"\

  - in windowPropTable[] we see next format for WM_HINTS_DFORMAT:

    {"WM_HINTS",	XA_WM_HINTS,	 "32mbcxxiixx",	WM_HINTS_DFORMAT },

 - so this is 3rd param ($3), and have 'x' format character

  - from "man xprop" we see that

x      The field is a hex number (like 'c' but displayed in hex 
c      The field is an unsigned number, a cardinal.

   - but what is cardinal? let's see in xprop.c again:

    in Format_Thunk() function:
      case 'x': return Format_Hex(value);

    Format_Hex() function defined as follows:

static const char *Format_Hex (long wrd)
{
    snprintf(_formatting_buffer2, sizeof(_formatting_buffer2), "0x%lx", wrd);
    return _formatting_buffer2;
}

    - so format is "0x%lx", and variable is "long" (for bitmap id)

Conclusion: "bitmap id" is really 64-bit, and displays correctly via "xprop", the only thing to understand is that this "bitmap id" little enough to be displayed similarly to 32-bit value.

Hello!

This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5.

Accordingly, we hope you understand why we must close this bug report. If the issue described  here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham