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