------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=107487         




------- Additional Comments From lars.doelle on-line de  2006-06-26 17:47 -------
All,

i think, this is it.

i fixed the transparent-MC bug, i wrote about earlier, tested 3 byte colours, added a
related testscript and tested printing.

Try the ./tests/ct2 (or ./tests/colortest.sh, if you can stand blinking)
and the ./tests/color-spaces.pl, all perhaps using various schemata.

Printing is at least not made worse, as i discovered a bug, but it was already
there. To reproduce it, set the "Linux color" schema, say "man man" and
print using "Pixel for pixel" and "Printer unfriendly" option, to find the highlighted
text not being printed. I did not dig into further it, may be, it is only because it prints
boldly white on white ;^). Default colors should perhaps be treated differently
while printing.

The only other thing, i believe is somehow fishy, is the "0xff" stuff reverted by me in
TEWidget::clearImage. If it ever meant anything at all, which i doubt meanwhile, it
should have broken something that i'm not not aware of, but i don't see what and it
does not have any negative effect in any test. I suppose, the "0xff" is a is a left-over
of some testing, really. Actually, the values set in clearImage should not really have
an effect as long as not paintEvent happens before a setImage comes, which should
happen only during program startup, perhaps, in which case the current setting is a
better default. As no special treatment of "0xff" in setImage is done (and what should
this be?), i would consider this one save either.

-lars


Created an attachment (id=16793)
 --> (http://bugs.kde.org/attachment.cgi?id=16793&action=view)
colorspaces-002.patch
_______________________________________________
konsole-devel mailing list
konsole-devel@kde.org
https://mail.kde.org/mailman/listinfo/konsole-devel