[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 |
Hello.
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!")
Thoughts?
-E
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.
- A colouring api that doesn't suck,
Elijah <=