It's not using ncurses nor terminfo, but it's very misleading to point to a list of VT100 escape sequences when it most definitely is not doing things the VT100 way either.
In contrast to the monochrome VT100 this is using colour quite significantly, albeit not supporting the recent corrections of a widespread mistake; and it even seems to support the rare framed and encircled attributes of later ECMA-48. Also in contrast to the VT100 it nowhere seems to deal in double-height or double-width, nor is it using ECMA-35 character set switching.
THanks!, I ask because I am starting a new project to create a terminal based gui and my research led me to think the ncurses was a solid choice, are you experienced with the terminal gui ecosystem, what are your thoughts on starting a new project with ncurses?
It's really a Textual User Interface when one uses terminal I/O, not a Graphical UI.
Personally, I did start a new project with ncurses. I wrote console-ncurses-realizer before I wrote console-termio-realizer in the nosh toolset. But I hit the limitations of ncurses very quickly.
There are lots of problems with ncurses, and the terminfo system that underpins it. They include the model of BCE not matching how terminals actually work, function key processing involving string matching instead of proper parameter parsing, little to no distinction between calculator keypad and editor/cursor keypad keys, "cursor addressing mode" not being what terminals actually do, ECMA-48 processing being needed in both directions, the "colour pair" system not really matching any terminal's handling of colour since the 1970s, and the continued use of ECMA-35 7-bit/8-bit character set switching (a cause of a vast amount of end user headaches down the decades) rather than Unicode for things like block graphics and box drawing characters.
If one starts again from first principles and comes up with a terminal capabilities system now, one comes up with a rather different set of capabilities and an ECMA-48-plus-ITU-T.416-plus-UTF-8-plus-some-DEC-VT model. One comes up with a far better model of the colour mechanisms, for starters. The library at hand employs it, as does my library.
And there are, as the headlined library shows, UI libraries that do this. There are problems with some of these libraries, as with the headlined library here for example and lack of support for TERM=dumb, which is still a mechanism that is very much in use. (My library allows for it.) But for programming languages from C++ to Python one has been able for some years now to find libraries that aim to replace terminfo with something better, and build up to approximately the level of abstraction that one gets in ncurses with panes and windows and suchlike.
Of course, those library implementors themselves also discover how bad some terminal emulators are at even some of the 1976 basics such as reverse video; that some terminal emulators are actively regressing from 1980s video terminal semantics to 1960s paper terminal semantics; and that there are still parts of the 1990s editions of ECMA-48 that no terminal emulator has implemented until this year.
If you feel comfortable with the idea that you or your users will never in the 21st century encounter a terminal that doesn't understand ECMA-48 and ITU T.416 and UTF-8, with varying degrees of DEC VT added in, then yes you probably should consider libraries such as the headlined one and others like it. Now that Unicode 13 is here, you can even ask their authors to allow using MouseText for TUI window borders and gadgets, a bold step forward into the 1980s. (-:
On the other hand, if you are comfortable living within the constraints of a C language API, limited keyboard and colour models, and the various mismatched paradigms, because you won't be pushing any of their boundaries in your TUI, then ncurses is there for you.
On the gripping hand, if you want WIMPs, there's always the option of writing a GUI application.
