Writing Programs with Ncurses
invisible-island.net
invisible-island.net
Then I found Textual (Python library, https://textual.textualize.io/) which feels like its modern and prettier child. Not gonna lie, it's still not a turnkey solution that transformed my clumsy scripts into a beautiful TUI without work but it's close!
They probably went to efforts to make it work an ancient system. But you really didn't have to.
Tunneling through the layer of crust accumulated in order to support Unicode (several layers of crust as Unicode evolved) was probably the most interesting of all.
A competent programmer could fit the whole charset in their head and easily write a TUI from scratch in a day. But they didn’t need to: plenty of great libraries existed.
Everything is so much easier when you have standardized hardware instead of layers upon layers of abstractions supporting all sorts of weird things, like we have to put up with this century.
ncurses renders to an underlying framebuffer which contains 32-bit Unicode characters, plus attributes (FG/BG color pair, and 8 additional attributes like underline, bold, blink). I'm not sure which layer of crust this framebuffer belongs to -- something related to TERMINFO, I think. The intermediate framebuffer is then rendered to the actual VGA framebuffer in a separate pass, which maps 32-bit unicode characters onto glyph indexes in the currently-loaded VGA font.
There are some provisions for Asian character sets (Vietnamese, for example, is plausibly supported). I'm not sure if Chinese or Japanese VGA terminals were ever adequately supported in Linux.
Can you elaborate on that? Are your "clumsy scripts" written in Python, shell or another language? Have you tried Textual-based tools like Trogon [1] and Moulti? [2]
[1] https://github.com/Textualize/trogon [2] https://moulti.run/
Thanks a lot for sharing these, especially Trogon, which I think is a clever idea with high ROI.
That being said, if you're doing something less involved, controlling the terminal via ansi escape sequences is not rocket surgery.
https://en.wikipedia.org/wiki/ANSI_escape_code
https://github.com/codr7/sharpl/blob/main/src/Sharpl/Term.cs
This sets the document at a particular point in time … in a lot of ways a better point in time.
I really miss the mid-90s computer scene. Things worked, often well, and in comparison to today they were so low-latency!
Not all of them are good, but there are way better chances that I like it than the 'other one' (3D game / GUI).
I think the reasons are similar. When you don't have to focus so hard on what it should look like you spend more time on whether it is a pleasure to use.
Ages ago on a mini I use to program, there was a very simple library I could call to format a screen. You told it modifiable field type and its text plus position on the screen. The screen was fixed at 80x24 plus no popups.
I wish there was a simple wrapper for curses like that :)
In the DOS Days, zortech c had a nice set of functions for screen input, disp_*, those were easy for my simple mind to understand to.
What I would like is a (n)curses library that uses a graphics back end instead of a TTY, preferably written in Go. I want a GTUI (Graphical-Text User Interface 8-)
Side note, Anyone know a site that curates a list of TUI designs? And not just good ones but examples of bad and weird.
(there's usually delay between Esc taking action, one should press it once and then wait a second until it takes effect)
Bytes arrive serially, one at a time, one after another.
There is no predictable garanteed time between bytes. Any two bytes in the stream may arrive with any amount of time between them, 1 ns, 1s, 1 hour, 1 week...
So anything that reads the bytes must have some sort of timeout whereby on seeing an esc, it waits up to some time for the rest of the escape sequence before giving up and treating the esc as a lone byte or a byte that was not lone but not not part of an escape sequence either. IE, no recognized termcap code ending with ";" etc. During that time it may be either waiting while no bytes are coming in, or it may be collecting bytes that haven't yet added up to some known terminal control code.
Normally even a very long valid escape sequence would all come in a fraction of a second, and so you'd think a tiny timeout like 0.1 second would be fine, but there are such things as far slower baud rates, and even if your immediate terminal has an infinite baud rate, some link in the unknown chain to your terminal could be any other speed, and there can be unpredictable pauses in otherwise fast baud rates. Even on the modern internet the timeout needs to account for some router hiccough anywhere in the 1000 miles between the source & your terminal.
Most apps that want to use esc as a direct "normal" key need to either use raw mode if that's even an option, or make the user type "esc-esc" instead of just "esc", and because of that, they just shouldn;t even be trying to do that in the first place, they should know better. It's not a good key to use for "abort" or anything else unless your environment is windows or dos.
these days it's not so bad (probably because mainly working with linux these days), but when i was younger and working with different Unices, getting terminal to work properly involved lot of effort and internal screaming "Y U no work!"
i'm still curious about this, please :) a relevant link will do
I don't have a link. Basically only a problem when sshing (or telent, or serial) between linux and any of the older unixes and somewhat to current freebsd.
The break key is not really a terminal function, it's a tty control code, displayed and set by th stty command. It must be a single byte. It can be set to basically any value, but can only be a single byte.
On linux, both the console which is TERM=linux and most gui xterm-alikes which are mostly TERM=xterm-something, both of which are somewhat similar to vt220:
break aka stty intr is 0x03 (^C),
backspace aka stty erase is 0x7f (^?),
and the Del key emits a multi-byte sequence 0x1b5b337e (^[[3~ aka esc[3~)
break / stty intr is ^?
backspace is ^H
the Del key emits ^?
When sshing in either direction between the two systems, unless you install good terminal definitions for each terminal in the other systems termcap & terminfo, AND, add code to .profile to change stty settings based on the detected $TERM on login, you end up with super annoying things where in one direction pressing backspace blows away whatever you were doing because it's like pressing Ctrl-C, or in the other direction backspace does nothing or prints a visible "^H" or something, but pressing Del acts like backspace.
As a service provider moving users from sco hosts to linux, the users have been pressing Del for 10 to 15 years (20 years ago now), but a linux terminal emulator does not emit a single byte from it's Del key. The Del key CAN NOT be assigned to be the break key because it emits a multi-byte sequence not a single byte.
All fine for most users because they can use a terminal emulator that emulates scoansi instead of linux or xterm etc, and so for the bulk of normal users it's possible to make everything exactly the same, no change with the move to linux.
But the console can not be made to emulate the sco console without such dirty hacks that I just refuse to do it. I lie and say it's not possible.
And usually the business owner would use the console so it needs to behave the same as all the other terminals. None of these people are IT people. They don't ever actually see the bash prompt, just login directly to an application. They are like cashiers before barcodes who get real fast with muscle memory blazing through menus and screens without even looking, and so there can be no mix of different terminals with different rules and different keystrokes etc, and you can't be changing that single button Del for break that they press a zillion times an hour to some two button hot key like Ctrl-C.
No one hits any of this today because there is mostly no such thing as a regular user that logs in to a terminal at all, and those few that do access shells get the same xterm pretty much everywhere and there almost isn't any such thing as a console any more.
yes, exactly those things :)
many thanks for the explanation, love your insight. cheers!
It seems to have a fair bit of support.