bastian at kde.org
Tue Jul 22 18:03:20 EEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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 kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
More information about the xdg