[prev in list] [next in list] [prev in thread] [next in thread] 

List:       konsole-devel
Subject:    [Konsole-devel] [Bug 107487] Please add the xterm-256 colour
From:       Lars Doelle <lars.doelle () on-line ! de>
Date:       2006-06-07 22:50:56
Message-ID: 20060607225056.1754.qmail () ktown ! kde ! org
[Download RAW message or body]

------- 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
_______________________________________________
konsole-devel mailing list
konsole-devel@kde.org
https://mail.kde.org/mailman/listinfo/konsole-devel
[prev in list] [next in list] [prev in thread] [next in thread]