[Konsole-devel] [Bug 107487] Please add the xterm-256 colour support.

Lars Doelle lars.doelle at on-line.de
Wed Jun 7 22:50:56 UTC 2006


------- 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-08 00:50 -------
On Wednesday 07 June 2006 21:01, awendt putergeek com wrote:

> > E.g. are colors of
> > text already written supposed to be preserved or changed when the
> > interpretation changes via ESC]4? How is transparency to be dealt with in
> > light of the extended color space?
>  
> The behaviour of xterm is that the colours are updated everywhere when a 
> palette change occurs.


One could do it this way, problem is, that the screen has to be fully redrawn.
Redrawing normally uses a differential algorithm based on the screen contents,
which is not changed by that operation. As 256 colors are likely to be set in
one go, this would mean 256 redraw operations. It would have to be integrated
somehow in the regular bulk operations, which likely delays the regular drawing.

> How would transparency be a problem?


Each color has a transparency attribute, too, in the konsole. They can be set individually
in the schema definitions. Not too big an issue. Another point is a rendition attribute,
intense colors. Normally, the konsole would thus have 2*(256+2) colors. I'm not sure
whether it is better to fully integrate the 256 color feature or to tack it at aside.

-lars



More information about the konsole-devel mailing list