Author here! Aside from Terminal.Gui, most of my GUI experience comes from SwiftUI on iOS and Mac. However, C# also has another cool terminal library called Sadconsole (https://sadconsole.com/) which I've used in the past to work on a Roguelike(https://markjames.dev/2020-05-21-making-a-roguelike-in-c-wit...). According to the developer, "SadConsole is an MonoGame 3.7-based game library that provides an engine to emulate old-school console and command prompt style graphics. One or more textures are used to represent the standard ascii character set. SadConsole allows you to create console instances which can be managed independently of each other. A console is made up of individual cells which can have a foreground, background, character, and a special effect applied to it."
Free Pascal comes with Free Vision, a fork of Turbo Vision. I suspect it's still the fanciest TUI library around in terms of what you get out of the box - FP's own text-mode IDE is written using that library.
Turbo Vision was also ported to modern C++, although I'm not sure what the quality of those ports is.
My dad basically tricked me into learning programming through Gorilla. "How about instead of playing games I show you how to MODIFY the games?" and I took the bait.
It looks like a nice project. I've also felt the urge to do some TUI programming recently. Actually, I also thought a simple music player was a nice way to do that. Must be the home-office effect (??)
Does anyone have some resources to learn how (UNIX) terminals work under the hood and how one can achieve nice graphic effects with it?
Also, is ncurses still the go-to solution, or do people use something like termbox or something else?
Here's what to learn, leaving how to learn it up to you.
---- PROGRAMMING TERMINALS THEMSELVES ----
The standards that you need to have to hand are ECMA-35, ECMA-48, and ITU T.416 .
* Most of the parts of ECMA-35 won't apply if you target UTF-8 terminals. The standard in the most part deals with switching 7-bit character sets in and out, the "ISO 2022" mechanism that you may have heard about that makes terminal output illegible. But ECMA-35 is still the explanation of escape sequences as a general concept, even though character set switching using some specific escape sequences is becoming a thing of the past.
* ECMA-48 deals mainly in control sequences, which are not escape sequences, and do not necessarily even begin with escape sequences (since in this almost wholly 8-bit-clean world C1 control characters can be sent as-is). The structure of control sequences is quite regular, and explicitly allows for vendor-defined "private" control sequences.
* The relevant parts of ITU T.416 deal in the SGR control sequences for colour changes beyond the 8-colour model of ECMA-48. These deal in "indexed" and "direct" colour, i.e. 256-colour and 24-bit colour in practice. Note that there's a very common misrepresentation of these control sequences, that fails to have colon-separated sub-parameters and fails to then get the sub-parameters right; so don't consult WWW samizdat sources on these control sequences. Terminal emulators have been moving to get this right over the past few years, coming to understand the correct control sequences, but that hasn't stamped out or fixed the reams of incorrect doco floating around the WWW and elsewhere for almost three decades.
The extensions to the standards that you need to be aware of are:
* The DEC VT extensions, most of which are private control sequences in the form that ECMA-48 designs in. These range from area attribute fills (DECCARA) to cursor shapes (DECSCUSR). The programmers' reference for the DEC VT525 is a good reference for this, but note that no terminal emulator actually fully emulates a DEC VT525.
* The AIXterm and DTterm extensions. AIXterm extended SGR control sequences from the ECMA-48 8 colours to 16 colours. DTterm repurposed (at the time) almost never used parameter values in a private DEC VT control sequence (DECSLPP with 0 to 24 lines per page) to mean entirely different things, related to DTterm's graphical user interface.
* The Xterm extensions, relating to mouse reports that aren't in the style of the DEC Locator, and other things. Note that the XTerm mouse report formats evolved, as problems were discovered. The one enabled/disabled by Private Mode 1006 is the most sensible, albeit that some mouse button up events confuse VIM, and DEC Locator reporting still works and is almost as good.
Also note that it is ECMA-48 in both directions. Most softwares, including ncurses, get this wrong and do pattern matching, but keyboard input is in fact encoded as ECMA-48 control sequences. In particular, note that the DEC VT conventions, laid out the VT52x and VT42x programmers' references (You have to consult both for the full picture.), encode modifier keys as control sequence parameters. DECFNK is a control sequence to be decoded in the ECMA-48 way, not a pattern to be matched; and furthermore no terminal in practice uses the FNK control sequence from ECMA-48. Also note that (U)RXVT has a totally botched input encoding system, best addressed by fixing the terminal emulator.
---- UNIX TERMINAL I/O ABSTRACTION ----
On the Unix side you need to learn about the line discipline, how to temporarily turn almost all of its mechanisms off whilst your TUI is active, and how to properly handle SIGTSTP, SIGTTIN, SIGTTOU, and SIGCONT signals. You also need to learn about the TERM environment variable, and fallback conventions to turn complex user interface features of...
I'm wondering if MPD is still a thing.
I've not used it in years, but it split the UI and server side meaning multiple people in an office could all control the same playlist and player that worked rather nicely. There were also a mix of cli and gui front ends catering for different user preferences.
It is, and I'm a regular user with ncmpcpp. Still works great; my only complaint is that it was a little fiddly to set up media controls (though that's true of anything involving audio/bluetooth on linux.)
Depending on how much effort you want to put into it, you may be able to use prompt-toolkit with IronPython (would have to use version 2.0 of prompt-toolkit since that supports Python 2.x) and then reference that in your C# applications
Awesome to see more Terminal UI like this :) - Reminds of Turbo/Borland Pascal's Turbo Vision days, and I'm great user of FAR Commander too (another great terminal app with good console UI), also midnight commander (on Linux, OSX, etc.)
33 comments
[ 42.1 ms ] story [ 1524 ms ] threadRegarding Terminal.GUI , the library looks very good and easy. Do you have recommendations of GUI libraries for other languages ?
Turbo Vision was also ported to modern C++, although I'm not sure what the quality of those ports is.
If you actually want a cli audio player. Been using it for few years already, it's amazing how lightweight/great it is.
However, I recall writing basically the same functionality as a QuickBasic library back in the DOS days. It's funny how things go full circle.
* https://github.com/jdebp/terminal-tests/blob/master/PowerShe...
https://www.qbasic.net/
https://www.qb64.org/
Someone know a lib for that?
https://github.com/prompt-toolkit/python-prompt-toolkit
Does anyone have some resources to learn how (UNIX) terminals work under the hood and how one can achieve nice graphic effects with it?
Also, is ncurses still the go-to solution, or do people use something like termbox or something else?
---- PROGRAMMING TERMINALS THEMSELVES ----
The standards that you need to have to hand are ECMA-35, ECMA-48, and ITU T.416 .
* Most of the parts of ECMA-35 won't apply if you target UTF-8 terminals. The standard in the most part deals with switching 7-bit character sets in and out, the "ISO 2022" mechanism that you may have heard about that makes terminal output illegible. But ECMA-35 is still the explanation of escape sequences as a general concept, even though character set switching using some specific escape sequences is becoming a thing of the past.
* ECMA-48 deals mainly in control sequences, which are not escape sequences, and do not necessarily even begin with escape sequences (since in this almost wholly 8-bit-clean world C1 control characters can be sent as-is). The structure of control sequences is quite regular, and explicitly allows for vendor-defined "private" control sequences.
* The relevant parts of ITU T.416 deal in the SGR control sequences for colour changes beyond the 8-colour model of ECMA-48. These deal in "indexed" and "direct" colour, i.e. 256-colour and 24-bit colour in practice. Note that there's a very common misrepresentation of these control sequences, that fails to have colon-separated sub-parameters and fails to then get the sub-parameters right; so don't consult WWW samizdat sources on these control sequences. Terminal emulators have been moving to get this right over the past few years, coming to understand the correct control sequences, but that hasn't stamped out or fixed the reams of incorrect doco floating around the WWW and elsewhere for almost three decades.
The extensions to the standards that you need to be aware of are:
* The DEC VT extensions, most of which are private control sequences in the form that ECMA-48 designs in. These range from area attribute fills (DECCARA) to cursor shapes (DECSCUSR). The programmers' reference for the DEC VT525 is a good reference for this, but note that no terminal emulator actually fully emulates a DEC VT525.
* The AIXterm and DTterm extensions. AIXterm extended SGR control sequences from the ECMA-48 8 colours to 16 colours. DTterm repurposed (at the time) almost never used parameter values in a private DEC VT control sequence (DECSLPP with 0 to 24 lines per page) to mean entirely different things, related to DTterm's graphical user interface.
* The Xterm extensions, relating to mouse reports that aren't in the style of the DEC Locator, and other things. Note that the XTerm mouse report formats evolved, as problems were discovered. The one enabled/disabled by Private Mode 1006 is the most sensible, albeit that some mouse button up events confuse VIM, and DEC Locator reporting still works and is almost as good.
Also note that it is ECMA-48 in both directions. Most softwares, including ncurses, get this wrong and do pattern matching, but keyboard input is in fact encoded as ECMA-48 control sequences. In particular, note that the DEC VT conventions, laid out the VT52x and VT42x programmers' references (You have to consult both for the full picture.), encode modifier keys as control sequence parameters. DECFNK is a control sequence to be decoded in the ECMA-48 way, not a pattern to be matched; and furthermore no terminal in practice uses the FNK control sequence from ECMA-48. Also note that (U)RXVT has a totally botched input encoding system, best addressed by fixing the terminal emulator.
---- UNIX TERMINAL I/O ABSTRACTION ----
On the Unix side you need to learn about the line discipline, how to temporarily turn almost all of its mechanisms off whilst your TUI is active, and how to properly handle SIGTSTP, SIGTTIN, SIGTTOU, and SIGCONT signals. You also need to learn about the TERM environment variable, and fallback conventions to turn complex user interface features of...
https://nick-black.com/dankwiki/index.php/Notcurses
Discussed: https://news.ycombinator.com/item?id=23402470
[1] https://github.com/kiddico/lit/tree/master/video_playback
Is there something like this for Python? I know Curses module exists, but this seems more full featured.
[1] http://urwid.org/