date DND

Waldo Bastian bastian at
Tue Jul 22 18:03:20 EEST 2003

Hash: SHA1

On Tuesday 22 July 2003 14:50, Owen Taylor wrote:
> On Tue, 2003-07-22 at 08:36, Waldo Bastian wrote:
> > 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.

Well, the obvious fix would be to teach Qt about the difference between 8 and 
16 but that might be a slightly complicated since it will require changes in 
the Qt API. TrollTech doesn't like to introduce API changes in minor versions 
and Qt 3.2 is about to be released so it might take a while before it gets 

Anyway, I will bug the Trolls about it.

> > 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.

So as a short term solution, GTK+ could perhaps also allow 8 so that it would 
at least work for the common case.

> 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.


- -- 
bastian at -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


More information about the xdg mailing list