[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A colouring api that doesn't suck

From: Elijah
Subject: A colouring api that doesn't suck
Date: Sat, 10 Aug 2019 19:42:45 +0000


Currently, the way you make something coloured with curses is to make a 
colour pair associated with the foreground and background colour you 
want, run attron() on that pair, and then draw the thing (and then 
attroff() the pair again).

I don't think it should be this way.

The reason it is this way is that curses dates from the 80s, when highly 
coupled software architectures were common, and specifying colour in 
this way fitted well with existing code.  In modern, more data-oriented 
architectures, it is more of a hindrance than anything.  (It also is an 
artificial limitation on the number of colour fg/bg pairs which can be 
displayed on the screen at once, but this is less of an issue in practice.)

It also encourages tight coupling with curses.  For example, by 
associating curses colour pairs with objects which are to be drawn. 
This fine for applications which /are/ tightly coupled with curses and 
intentionally so, but makes it much more difficult to wrangle for those 
that have more generic output.

/This is causing people to stop using ncurses./  Partly, they are using 
alternatives such as termbox (https://github.com/nsf/termbox), but more 
frequently what I see (and have to write all too often) is something 
like this (pseudocode):

void print_with_colour(string str, int fg, int bg, int y, int x) {
        if (!colour_table contains (fg, bg)):
                colour_table[fg, bg] = colour_table.length + 1;
                color_pair(colour_table.length, fg, bg);

        attron(COLOR_PAIR(colour_table[fg, bg]))
        mvprintw(y, x, str);

/This means that the abstraction provided by ncurses is not the right 
one for people, so they are working around it./

Let's do something about it!

I propose to add to ncurses' api _ext-suffixed versions of functions 
that draw things (e.g. mvprintw_ext).  These will take an attribute 
parameter (or two?) as their first parameter, with colours specified 
directly instead of as a pair, and ignore any settings set by attron(). 
So for example, I might say something like this:

mvprintw_ext(A_BOLD | A_ITALIC | FG_CLR(47) | BG_CLR(125), 5,5, "Heyo!")



P.S. perhaps this opens up the floor for truecolour support?  AFAIK 
there are currently 13 attributes that go into an attr_t at the moment. 
If the *_ext() functions took a 64-bit attribute, then that would leave 
room for 24 bits each of foreground and background, one bit each to say 
whether fg and bg are truecolor or indexed, and an extra bit.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]