[Konsole-devel] [Bug 107487] Please add the xterm-256 colour support.
Lars Doelle
lars.doelle at on-line.de
Sun Jun 11 20:34:41 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-11 22:34 -------
Witold,
> what about to go one step further and use ESC[38;5;2;<red>;<green>;<blue>m
> codes? foreground and background as UINT16 gives 65536 colors and only two
> bytes more per cell.
It should read ESC[38;2;<red>;<green>;<blue>m, i guess.
While you're at it anyway, please make up your mind how to implement this. Colours
are all indexed right now. It would perhaps be most natural to define something like
colour spaces. You could consider a UINT32 for the fg/bg colour in class ca leaving
you a full byte for defining the colour space identification.
(Hmm, you need to check for "_fg" and "_bg" in TEScreen.h, too, when changing class
ca as there are some state variables for the current and the saved colours.)
If you choose to introduce colour spaces, you could basically leave schema.cpp as it was.
Using colour spaces would allow to actually locate the colour interpretation into function
used by TEWidget::drawAttrStr, where you could extend the colour indices and RGB
colours algorithmically. As true RGB color would be provided, too, there were not much
need to set the 256 to anything but the default. Just an idea.
I note that the 256 color space includes 16 "system colors", actually it appears to be
intended to include the "normal" colour space.
> I don't know which formula to use it to define intense 256 colours.
In a HSV-model, i would increase the V, i.e. multiply each RGB colour component by
some same factor > 1. This might mean to dim the "regular" colours first.
If you are using an 6x6x6 colour cube anyway, this is best done algorithmically instead
expanding a table, as this eases later adjustments. This concerns both the tables
'color_name' and 'default_table' in schema.cpp. The default_table is actually just a
default in cases when no schema is installed. The schema.cpp was defined for the
system colours, only, i'm not certain whether it is good idea to extend the schemata
beyond these.
> I can code it, but next week, not now.
No need to hurry. 256 colours are in xterm since 1999, so konsole can almost certainly
wait one week more. Please ask if you run into problems.
-lars
More information about the konsole-devel
mailing list