otaylor at redhat.com
Tue Jul 22 15:50:24 EEST 2003
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->target, 8, PropModeReplace,
> (unsigned char *)a.data(), a.size() );
> And a.data() essentially refers to ushort 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.
More information about the xdg