date DND

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
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 
fixed.

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.

Appearantly.

Cheers,
Waldo
- -- 
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

iD8DBQE/HVI4N4pvrENfboIRAmGaAJ43onLESQLPW7rexG5BF77H2SiDzgCfdr9m
WS5TVSXBs9RUooJ7TgPAI8c=
=KIbg
-----END PGP SIGNATURE-----