Re:TUI Demo – Terminal Interface to Mastodon
by dredmorbius on Saturday September 07, 2019 @10:36PM
(#20908249)
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).
There are full TUI windowing environments, such as TWIN: https://sourceforge.net/projects/twin/
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).