date DND

[Owen Taylor]

On Tue, 2003-07-22 at 08:36, Waldo Bastian wrote:

> > The contents look like little-endian 16 bit data, so I wonder
> > KColorChooser can DND to itself across endian properly?
> 
> Amazing how people manage to interpret such a simple spec still quite 
> differently :-}
> 
> I'm not really very deep into this stuff, but Qt does:
>         XChangeProperty ( QPaintDevice::x11AppDisplay(), req->requestor, 
> req->property,
>                           req->target, 8, PropModeReplace,
>                           (unsigned char *)a.data(), a.size() );
> 
> And a.data() essentially refers to ushort[4] so I don't think kcolorchooser 
> has a chance of working across endianness.
> 
> Does the 8 in the XChangeProperty call refer to your data.format above? Would 
> there be some sort of endian-conversion if it was 16? Where?

Yes, the 8 is the 'format' in X terminology. The X server would
take care of byte-swapping the contents of the property if the 8
was 16. (Each client communicates with the server in its native 
endian, the server swaps.)

If Qt can only handle format-8 properties, than that's something
we need to take into account in any drag types we standardize...
the date DND format that Matthias proposed was also format-16.

> What is surprising (frightening?) is that the code in KDE is from 1999 and has 
> as comment: // A short int for each of R G B Alpha (compatible with gtk);

Well, it is sort of compatible with GTK+ as long as both machines are
the same endian... the bytes of the data are the same. It works for
dropping into KDE, since Qt isn't checking the format, but GTK+ checks,
sees that the format is 8 and rejects the drop.

As far as I can tell, GTK+ has always checked the format, so it seems
that the person who wrote the KDE code only tested in one direction.

Regards,
						Owen