On Thu, Jan 23, 2014 at 10:34 PM, Thomas Dickey <address@hidden> wrote:
some of which points out that it would be nice if someone else did the work :-)
:-)
The tricky part here is that the work needs to start with designing, which requires someone with deep understanding of ncurses, probably Thomas you're the only one who has this knowledge.
Do we go for an ABI-incompatible change, so init_pair can take int32s, bumping the major SO number to 6? If we do so, are there any other ABI-incompatible improvements that can/should be put in that version?
Or do we go for an API extension, introducing init_pair_true() and alike functions?
Actually, do we want to keep the current indexed approach? For apps that would use a reasonable number of colors, each for a certain context (e.g. text editors with syntax highlighing, midnight commander, etc.), this approach would be sufficient and the easiest to migrate to. For apps similar to elinks (which uses for each charcell the exact color specified in html/css) this approach would probably be very hard to use, they'd probably prefer direct access: just as each charcell can have its Unicode character directly, similarly they'd probably prefer to set for each charcell the attributes and the fg/bg colors directly (whereas the colors could be either the index to the 256-color palette, or direct RGB) -- rather than going through ncurses's color_pair mapping. This would require much heavier changes to ncurses, obviously maintaining the backwards compatible color_pair approach too.
Just some random thoughts from someone who has hardly done any ncurses programming... but would love to have true color support :)