webcore 106 color handling changes

[David Hyatt]

I may have made incompatible changes here, because perhaps I don't 
understand how QRgb works in Qt.  In the Safari tree, we support the 
ability to specify rgba quadruples in CSS.  This means that a color 
with an alpha component is perfectly valid and specifiable using CSS.

Our QRgb is 32 bits, with 8 bits for each of the R, G, and B values, 
and another 8 bits for the alpha value.  Looking at constructions like 
qAlpha, I assumed that's how Qt's QRgb works as well.  Was I mistaken?

I do not understand why there would be no difference between "no color 
given" and the "transparent color."  If you simply construct a QColor 
it will be invalid, but once you explicitly set it to any RGBA value 
(including 0), it becomes valid.  Is that not how QColor is supposed to 
work?  Reading the docs it sounded like you basically needed an extra 
"valid" bit in the QColor class to accomplish this, and so that's what 
I did in KWQColor.

It's on my list of things to do in the Safari tree to eliminate the 
special-casing of transparent (i.e. ,the special bit in the bordervalue 
structure) and to just start testing for the transparent color instead.

On Oct 25, 2003, at 8:57 AM, Dirk Mueller wrote:

>
> Hi,
>
> --- WebCore-old/khtml/misc/helper.h     2003-10-09 21:01:59.000000000 
> +0200
> +++ WebCore/khtml/misc/helper.h 2003-08-04 12:16:06.000000000 +0200
> @@ -30,9 +30,8 @@
>  namespace khtml
>  {
>      const QRgb transparentColor = 0x00000000;
> -    const QRgb invalidColor     = 0x00000001;
> -    const QRgb invertedColor    = 0x00000002;
> -    const QRgb defaultTextColor = 0x00000003;
> +    const QRgb invertedColor    = 0x00000002; // This really makes no 
> sense.
> This is a valid color value, so why
> +                                              // is it being given 
> special
> meaning? -dwh
>
>      extern QPainter *printpainter;
>      void setPrintPainter( QPainter *printer );
>
>
> That commit (and the related changes in css/) makes no sense. it is 
> not a
> valid color in our tree, its a fully transparent color. These colors 
> are
> necessary to correctly calculate the default text color (when it is 
> modified
> by external stylesheets) to reset to when a <table> is opened in the 
> html
> compat case.
>
> It is also necessary to support border: transparent correctly, because 
> there
> is a difference between no color given (which means use the foreground 
> color
> for border) and explicit transparent color. And you have to transport 
> that
> into the rendering tree.
>
> So unless I miss somthing, this should be reverted.
>
>
>
> -- 
>> Looking for a KDE-related EMail-Alias ? Get one at kdemail.net for 
>> FREE! <
> _______________________________________________
> Khtml-devel at mail.kde.org
> http://mail.kde.org/mailman/listinfo/khtml-devel