[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:       <awendt () putergeek ! com>
Date:       2006-06-07 19:01:24
Message-ID: 20060607190124.1239.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 awendt putergeek com  2006-06-07 21:01 -------
> Is the 6x6x6 color cube predefined, btw.?


Yeah, it's in effect when Xterm first starts up. The colours are defined in  
256colres.h in the Xterm source. The first 16 are the regular colours 
(aliases, not duplicates, so I can get green with either 32 or 38;5;2, and 
the sequence \033]4;2;rgb:00/00/ff\033\\ will redefine text printed with 
either of them to be blue). The next 216 indices are for the 6x6x6 colour 
cube. The last 24 are a greyscale ramp.

> Hmm, changing the color format has some consequences. 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.

How would transparency be a problem?
_______________________________________________
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]