4 ms·
Some time ago I built a (terminal) text editor and one of the challenges is to implement the renderer which is normally done by messing with termios and changin
by zeptomu 9y ago
Some time ago I built a (terminal) text editor and one of the challenges is to implement the renderer which is normally done by messing with termios and changing some terminal parameters - as this is "device"-dependent there exist databases like terminfo and abstraction-layers like curses which give you an API similar to "Write this text at position x/y in green".
However curses and terminfo are big programs and most terminals they support are not in use anymore, so if one is OK with supporting just 99.9 (and not 99.999 like curses)% of modern terminals (say xterm, linux-console, st, urxvt, $otherterm), it is feasible to roll your own or use an alternative like e.g. termbox (https://github.com/nsf/termbox https://github.com/nsf/termbox).
It provides a simple API like "write Unicode-Char to position x/y in specific $style" and some utility functions to setup the terminal (e.g. one has to consider how to react to window-size (== terminal rows/cols size) events). You can then write your app similar to a game-loop like the following:
while state['should_run']:
render(state)
update(state)
get_input(state)
I think such an API is pretty nice to work with - this is different to the React approach, but for writing terminal GUIs like text editors it worked pretty well for me.
Many (native) games use a similar approach when rendering menu's and stuff and although there are terrible ones most menus of games look pretty slick.
- thomasballinger 9y ago(just to emphasize, I think parent understands this) The render function here can be stateful, React vdom-style: diff with previous output, efficiently update output based on the perf characteristics of a terminal. But it's an entirely separate domain, which is great for the developer.