date DND [Issue N27267]

Owen Taylor otaylor at redhat.com
Mon Aug 4 15:15:59 EEST 2003


On Mon, 2003-08-04 at 06:01, Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 04 August 2003 11:11, Matthias Clasen wrote:
> > [...discussion of non-interoperability of color drops KDE->Gtk...]
> >
> > > So as a short term solution, GTK+ could perhaps also allow 8 so that it
> >
> > would
> >
> > > at least work for the common case.
> >
> > The next releases of GTK+ will silently accept format 8 for
> > application/x-color drops.
> > I hope this doesn't stop you from fixing the root of the problem in the KDE
> > color chooser...
> 
> I have sent TrollTech a patch for it but haven't heared back on it yet. More 
> disturbingly is that the conversion from a 8 bit color representation (as 
> used by QColor) to 16 bit is basically wrong as well. It multiplies the 
> colors with 0xFF to go from 8 to 16 bits which tends to result in slightly 
> different colors compared with GTK. In fact, when you drag white from GTK to 
> Qt you end up with an invalid QColor because it goes out of bounds.

Multiplication by 0xFF is creative :-), a lot of people make the
mistake of multiplying by 0x100 rather than 0x101, but I've
never seen 0xFF before. 

(16bit => 8bit can/should be done as a simple shift rather than 
division by 0x101; far too much detail on this subject can be found
at http://people.redhat.com/otaylor/pixel-converting.html)


> So maybe it's actually better that it doesn't work at all till it has been 
> sorted out in Qt, rather than that it introduces subtle differences which the 
> user may not notice.
> 
> Qt bug tracking number is 27267

Hmm, we already put the change into GTK+ cvs a few days ago.

2003-08-02  Matthias Clasen  <maclas at gmx.de>
 
        * gtk/gtkcolorsel.c (color_sample_drop_handle)
(palette_drop_handle):
        * gtk/gtkcolorbutton.c (gtk_color_button_drag_data_received):
        Accept drops with the wrong format, since the KDE color chooser
        incorrectly drops application/x-color with format 8.


(http://bugzilla.gnome.org/show_bug.cgi?id=118810)

Unless the drag of white crashes KDE or KDE apps, it seems to me that
we might as well leave it ... an almost-right color drag probably
is useful in many cases, and shouldn't be worse than no drag.

Regards,
						Owen





More information about the xdg mailing list