Errors related to _NET_WM_ICON are found in wm spec

[Tomas Carnecky]

On 01/26/2009 04:08 AM, PCMan wrote:
> http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2552223
> This is mainly a 32-bit / 64-bit issue.
>
> The original spec:
> _NET_WM_ICON
> _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.
>
> The proposed revision:
> _NET_WM_ICON
> _NET_WM_ICON CARDINAL[][2+n]/32(or 64 if you are on 64-bit systems)
>
> 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 unsigned long integers (usually 32 bit, and could
> be 64-bit on 64-bit systems). Each element of the array contains a
> 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.

I'm missing the "why" part of your proposal.

But I think I know the why. It's unfortunate that the original Xlib 
developers decided to use 'unsigned long' for 32bit properties, even on 
platforms where 'unsigned long' is 64bit. But the actual data sent over 
the wire and stored in the server still is only 32bit. I know, this 
makes it impossible to load an image into memory and use it in 
XChangeProperty(), because you first have to convert it to an array of 
'unsigned long'. But you'll simply have to live with that 'limitation'.

tom