This is certainly well done. But, I don't get the point of complex TUIs. Granted - text consoles are useful because they allow programs to get input, output, and job control, and even text selection with very little effort. It can't get simpler than printf() and friends.
With more complex TUIs these points don't really apply. There is a lot of effort involved to get the layout right, so why not make it nice? Text selection isn't possible with windows (I guess? Do text terminals support this stuff?).
Font support is awful (only 1 font size, limited font styles), text is harder to read, and so on.
Terminal interfaces have an ergonomic advantage over traditional GUIs in that they are not painfully context dependent: dealing with keyboard focus is annoying and slows the user down. But, it's just a cultural thing and it's easy to make graphical applications with a TUI-like input model.
The only arguments in favor of TUI that I can see is that they are really fast to load up (compared to ~1 sec that it takes to create an OpenGL window) and that you can easily use them over an SSH connection.
A last argument might be that many window managers suck at switching between windows. What bash or tmux do might be more ergonomic for some people.
Text selection isn't generally necessary; but in a pinch, one can put a little more effort in to extract and format it.
Font support is excellent if you desire a single font and want it to look one way, all the time, and not be subjected to the whims of the data-provider.
It's true, in a TUI you almost _never_ experience the abhorrent pain of the Window system thinking it knows better than the user, and so your focus remains where you wish it to be, at all times, always.
The best argument in favour of TUIs is that the user is always the primary focus, their current application focus always remains so long as they desire it, the content restriction limits the visual variety, and the limitations coerce the interface to providing only necessary information.
> it's just a cultural thing and it's easy to make graphical applications with a TUI-like input model
I agree with your points, but I think this part is an important aspect to it.
Sure, people (or more likely "developers, writing for developers") could write GUIs which are as keyboard-oriented as TUIs. But I don't think there are many common examples.
With TUIs, it's more likely to be keyboard focussed and support plaintext file formats. (Again, that seems cultural).
Another advantage to TUIs is the flipside of "only 1 font size, limited font styles": with a TUI, the user can set the terminal emulator's colour scheme and font sizes.
Sometimes this won't work well. But it's a degree of customisation you don't really get with standard GUI programs, and isn't common for flashy websites.
I’m not saying these are the only two options by any stretch, but given the choice between a TUI and an Electron app there’s no contest. I like that a TUI is constrained by the view layer; that is there’s no images or videos to render, no HTML to parse into pixels. It keeps things naturally light and if it’s complex to use I’m fine with that too.
They also work on the server. You’d be hard pushed to find anyone who says installing an Electron app on the server is a good idea.
If you just make a TUI-style app in graphics mode, is it really that much harder? Granted, there's a bit of boilerplate for setting up a drawing context, and you might want to make your own minimalistic drawing framework (because windowing toolkits might be too much), but apart from that I'm not sure it's hard. And you even get image display for free! Plus an easy upgrade path for example for minimal mousing, keyboard combinations, etc.
They're also generally faster to launch and surf (unless you're doing a lot of updates, which requires double buffering and is still very dependent on your terminal's performance).
You also have to be more clever to pack information in a smaller section (typically < 100x100 character space), and you avoid unnecessary graphics that are distracting.
Yeah. Thinking about it, the appeal really to me is that I don't have to give a shit about fonts/colors/etc. I only care about the data. I'd live my entire life this way, if I could.
When you are only using Linux machines, X mostly just works, while correct terminal bahaviour and appearance depend on configuration and TUIs.
I'm not praising X nor am I shitting on TUIs, also I have indeed had more problems with X in general, but not when both host and guest were Linux machines.
I get this too often:
https://robert.penz.name/354/how-to-fix-the-font-for-virt-ma...
The gtk program decided on some font, but didn't have the audacity to request it as a dependency, so you end up with a GUI that prints crap for all text instead.
The problem is "easy" to figure out, the workaround is "easy" and the long term fix is also "easy" but for some reason, it still happens. Now if it would just fall back to whatever default X font there was, I would see text on all strings even with bad size/kerning/look but nopes. Blank squares is where we are at.
So when someone makes a program that just decides to print "Hello" by just printing out those chars on my computer, with my font (or the default, the system, the fallback) it is kind of nice that I at least can see what it tries to tell me.
X is dependent on you using a Operating system supporting X. Ssh can be used across all operating systems, even as an Android app. Sometimes that can be useful.
There are X servers for most major operating systems, including, AFAIU Android. For OSX it's XQuartz (either native or XTools), for Windows, MingX11 and I suspect WSL, as well as various proprietary tools.
I'm not arguing that X11 is more streamlined than remote SSH (or tmux!) in a terminal / console. But it is far more available than you might think.
Android is an interesting use case. It would probably be mostly useless to SSH from an Android if the TUI ecosystem wasn't so prevalent.
You probably also refer to Windows and MacOS, but that just corresponds to another type of difficulty (Xming, Xquartz), it doesn't make it inherently worse/impossible.
TUIs present a common access factor across a huge number of platforms and OSes. They allow for trivial remote access via SSH or tmux. Of the issues you raise, many are features, others are mitigatable.
It's possible to have windowed text environments, with Emacs being a standin for much of this, though tools such as tin (newsreader) and mutt (email) show this. What does seem to be missing is a standard development model for laying out subwindow regions and basic widgets analogous to many GUI toolkits.
The ability to specify fonts once and have ALL applications respect that choice is actually a major godsend. I spend more time battling various GUI tools over font specs than anything. The fact that many GUI toolkits and environments don't think that font should be specifiable on an application-specific, or instance-specific basis is particularly annoying. No, as a matter of fact, I may not want to have the same default body font size in all gtk / GNOME / Qt apps. Or across all of my GNOME Terminal windows. Or whatever else.
The fact that the font configurations are very seldom immediately accessible, and have to be dug out of various third-party configuration management tools, which have changed a dozen or more times over my use of Linux (even within a single toolset / environment) is all the more frustrating.
TUIs can support mouse interactions and text selection. This most often manifests for me as frustration as my preference is to use the keyboard for control, and the mouse only for text selection and copying. Nothing is more frustrating for me than to have some mouse-aware Vim variant that changes the active cursor location as I'm copying text from the screen.
TUIs also:
1. Generally have fewer dependencies than GUIs. Less stuff to break.
2. Are consistent across environments.
3. Are almost fully network-transparent.
4. Are highly responsive.
5. Are frequently far more stable.
6. Support multi-instance launching. Until w3m supported tabbed browsing, my poor-man's tabbed w3m browser was to launch w3m within screen. Twiddling with the $SHELL variable let me launch new w3m instances in newly-created buffers, but shell out to bash from within w3m itself.
7. Allows screen-recording through 'typescript'. Add the timings argument to save and reply realtime.
8. Frequently allow both interactive and noninteractive / batch use. (mutt as an example has multiple shell invocation features).
9. Frequently allow pipelining content in and out. I end a surprisingly large number of shell pipelines with 'vim -' these days -- noninteractively clean up crap, then dump to vim for a final interactive cleanup / edit.
Your last point, that window managers suck at moving between windows, is a massive pain point. OSX is simply staggeringly bad in this regard. I want to switch between specific window instances, not raise and lower entire motherlovin' applications. Again: I spend more time fighting the window manager (Aqua) than I do getting work done.
This isn't uniformly the case. My preferred Linux desktop, Windowmaker, as configured by me, has been for well over 20 years a simple, efficient, fast, stable, and highly capable tool. I can move between windows and apps, desktops, etc., as second nature. I've tried other desktops (GNOME, KDE, XFCE4, Cinnamon, and many simple WMs) but none match the faculty and features of Windowmaker. I might switch to a tabbed WM (a threat I've been making for a decade), but to date, that's not been worth the costs.
And emacs's buffer and text management is another huge productivity boon for many people (I don't use it now, though had in the past).
With more complex TUIs these points don't really apply. There is a lot of effort involved to get the layout right, so why not make it nice? Text selection isn't possible with windows (I guess? Do text terminals support this stuff?).
Font support is awful (only 1 font size, limited font styles), text is harder to read, and so on.
Terminal interfaces have an ergonomic advantage over traditional GUIs in that they are not painfully context dependent: dealing with keyboard focus is annoying and slows the user down. But, it's just a cultural thing and it's easy to make graphical applications with a TUI-like input model.
The only arguments in favor of TUI that I can see is that they are really fast to load up (compared to ~1 sec that it takes to create an OpenGL window) and that you can easily use them over an SSH connection.
A last argument might be that many window managers suck at switching between windows. What bash or tmux do might be more ergonomic for some people.