TrueColor (24 bits) support

Антон Кочков anton.kochkov at gmail.com
Tue Jul 28 18:27:06 CEST 2015


Hello!
Sorry for bothering about an unwanted feature and restoring an old
thread, but posting this just for the information.
There is a patched version (with 24bit color support) available in
github https://github.com/spudowiar/rxvt-unicode/tree/24bit

Best regards,
Anton Kochkov.


On Sat, May 9, 2015 at 2:29 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Thu, May 07, 2015 at 08:56:16PM +0200, Marcin Kurczewski <rr- at sakuya.pl> wrote:
>> Hmm... perhaps we describe it wrong; let me try again. While indeed we
>> can map some predefined colors to any RGB we want through user
>> settings, and runtime - by escape codes such as "\e]10...", it is
>> limited only to a few colors - we can change foreground, background or
>> any color in the 16 color palette, but that's it.
>
> Both xterm and urxvt let you change any colour, not just the first 16 ones,
> and afaics, for many many years, too.
>
> I don't know about other temrinals, but I'd be surprised if other
> temrinals had such a limitation either.
>
>> change the palette after printing something to terminal, what we
>> printed will change colors, too. This is ultimately the thing we're
>
> That is the point, yes.
>
>> 1. to be able to print any color in RGB cube,
>
> And as explained, you can already do that, you are not limited to the
> colours in the 88 or 256 colour palette.
>
>> 2. to have more colors to choose from than 88/256 Xterm color palette,
>
> And as explained, this is already the case.
>
>> 3. to be independent from 16 color palette / user settings, so that
>> what we printed stays the same, regardless of settings changes that
>> might come before or after.
>
> Again, this 16 colour palette limit does not exist anywhere, afaics.
>
>> I apologize if this is already implemented in any way.
>
> As explained multiple times, it's all imnplemented already, and for a long
> time.
>
> There is no need to apologise, but it would help if you stopped stubbornly
> ignoring when we tell you that it is already implemented. I feel like a
> broken record epxlaining this again and again.
>
> What is not going to be implemented is a full 24 bit palette - you are and
> will be limited to ~88 or ~256 simultaneous colours at any one time. To
> lift this limit, we would need a good reason why 256 colours is not enough
> - "I can make toy rainbows with libcaca" is not going to cut it.
>
>> I also understand if printing colored stuff in a way that completely
>> disregards user palette settings sounds bad to you.
>
> One would expect that ultimately, the user was in control, yes.
>
>> talk about the same thing. (And again, personally I see no harm in
>> adding support for such a custom extension that's to be used not too
>> seriously.)
>
> Me neither, but there is no "such a custom extension" at this point, there is
> not even a specification for what such a custom extension would do. To even
> *begin* to talk about such an extension you'd first have to explain what it
> is supposed to do.
>
> Simply askign again and again to implement "something" without telling
> what this something is, and ignoring people trying to be helpful in
> explaining how you can already do what you want is not leading anywhere.
>
> Implementing an extension that is incompatible to other terminals *is*
> harmful.
>
> --
>                 The choice of a       Deliantra, the free code+content MORPG
>       -----==-     _GNU_              http://www.deliantra.net
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>       -=====/_/_//_/\_,_/ /_/\_\
>
> _______________________________________________
> rxvt-unicode mailing list
> rxvt-unicode at lists.schmorp.de
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode



More information about the rxvt-unicode mailing list