I recently discovered VisiData and I'm on a huge TUI kick right now because of it. I know GUIs have their advantages and I use them, but opening a file in vim or VisiData at light speed feels so good compared to firing up IntelliJ or some spreadsheet program. Good keybindings make working in the program a joy. These tools are often made by hackers/for hackers, not some corporate structure trying to pad their resume with whatever new feature looks good but works like shit that nobody asked for. When people developing the tool are also using the tool you get a good tool; this isn't exclusive to TUIs but it's common and it's one of the reasons that when they work they work so well.
100% agreed. Also VisiData looks cool, thanks for the link. In this space, I'm a huge fan of Lnav (https://lnav.org) which fits similar use cases as a TUI / CLI for ETL workflows (w embedded SQLite), works great at the scale of a few millions of rows.
It is a little more niche but the inclusion of braille in Unicode and it’s impact on ascii art is comparable to IE’s XmlHTTPRequest, in terms of unexpectedly transformative moments in software history.
It's funny because displaying bitmaps in a terminal-like interface has been possible for many years. Even TempleOS[0] can do it! But somehow it's just never caught on. But the unicode thing works because it gets shoehorned into existing standards and functionality. Legacy is a bitch. "The things you own end up owning you".
Makes me wonder, though, is there enough space in unicode to just encode every possibly 16x16 bitmap? 256 bits?
> Makes me wonder, though, is there enough space in unicode to just encode every possibly 16x16 bitmap?
Space is not an issue here. You can do with very few characters, just make them combine with each other, like ˩˥ is encoded as ˩+˥, flags are encoded as combinations of two letters, etc.
So, you can just have 256 characters for each bitmap dot and make them combine with each other. Or have 16 characters and make them combine (maybe using zero-width joiner).
I think the biggest problem is actually getting this thing into Unicode. Emoji got codified because some Japanese phone encodings included them. But it would be harder to justify arbitrary bitmaps.
Or you could just have two new code points representing 1 and 0, which are only valid in sequences of length 256. Really stretches the meaning and purpose of a character encoding though…
As have other tools. R and its inspiration S had these, SPSS, SAS, SPlus, and who knows how many other stats programs over the decades, going back to the 1970s or even 1960s, mostly under Unix and mainframe platforms.
I've even written my own simple barplot program in awk for generating quick-and-dirty comparisons in shell scripts.
> R and its inspiration S had these, SPSS, SAS, SPlus, and who knows how many other stats programs over the decades, going back to the 1970s or even 1960s, mostly under Unix and mainframe platforms.
I've wanted something like this for ages. In fact I wanted something much simpler: just the ability to pipe tabulated data from a script into something and display it in tabular format. I wrote my own at some point but found too many quirks for it to be useful. Visidata can do what I need and much, much more. Awesome!
> Version 2.23 changed the -s option to be non-greedy
Elsewhere on an ancient Ubuntu I have lying around, `-n` did the same:
-n By default, the column command will merge multiple adjacent delimiters into a single delimiter when using the -t option; this option disables that behavior. This option is a Debian GNU/Linux extension.
Yeah, `column | less -S` works fairly well but empty cells and escaping etc. turns up too often. It essentially means you need a proper CSV parser, which is non-trivial. The other common problem was long values making the output unreadable. Some kind of default truncation is essential.
If IntelliJ was as fast as vim or VisiData, and as a bonus totally scriptable (I think it is to some extent, but just for fun let's assume you could change everything), which would you prefer then?
The value of IntelliJ (in my opinion) is the deep semantic processing of the language you are using to provide useful information/refactoring/linting capabilities. It blows the equivalent LSP stuff out of the water (or at least it did last time I tried it with Kotlin).
As an editor, I really hate it coming from vim. Even with vim mode, it sits in the uncanny valley for me. It's pretty close to vim, I'd say 95% of the stuff works as I'd expect, but the last 5% is jarring. My biggest annoyances are:
* The undo behavior is insane, I'm constantly double-tapping u, because undo brings your cursor back to your last edit, but doesn't undo it. Unless your cursor is already where it should be, then it will undo. So it's uu then ctrl+r (sometimes).
* They don't have vim tabs (I don't think any modern IDE does). I'm constantly closing and reopening splits, it drives me crazy.
* There's no toggle fold, gotta explicitly unfold/fold. That muscle memory is stuck with me now, even in vim which makes me sad.
* Moving between the different panels is not the same as moving between different splits. You need to memorize the hotkey for each panel and then the hotkey to get back to the code, it feels extremely unnatural. The vim hotkeys are hit or miss in the different panels as well.
Despite all that, I still used it when I was working on a Kotlin codebase. I wish it was possible to extract their language processing stack and use it in vim to have the best of both worlds.
> * The undo behavior is insane, I'm constantly double-tapping u, because undo brings your cursor back to your last edit, but doesn't undo it. Unless your cursor is already where it should be, then it will undo. So it's uu then ctrl+r (sometimes).
This is a much better way than stock vim. In vim, if I scroll elsewhere and undo, it jumps back to the last edit and already undone the edit and sometimes I'm not sure what got changed but in IntelliJ it jumps back first, so I can see what will change before it gets undone and also I can just use 'u' whenever I want to go back to the last edit's position.
I guess it depends what your typical case for undo is. For me, 99% of the time I remember the changes I made an want to undo them, so pressing a button twice is annoying, especially since it's not consistent. If I don't remember what I was doing, then I can press ctrl+r to redo and see what changed, but to me that is the exception and I'm fine taking extra clicks to do it. Everyone has preferences, I wish this was configurable :P.
> also I can just use 'u' whenever I want to go back to the last edit's position.
If IntelliJ was as fast as vim, as lightweight as vim, preinstalled on every machine that I use, fully accessible over ssh, as scriptable as vim (or had perfect vim emulation as a plugin), free, I could install all of my preferences with just some dotfiles, and I need an IDE for the project, then I suppose it would just make sense to use IntelliJ at that point. Sometimes you just need a text editor though.
I'm probably one of 2% of eng at my company who use vim instead of vscode, and not being able to run it in a terminal is the primary dealbreaker for me.
My dev workflow consists of 4-6 screen sessions with 3-5 terms each. Each one represents one "task" (usually a branch), and I use git worktrees to keep separate copies of the repo that are linked at the git object level. An IDE that insists on being a GUI makes me feel like I'm using a toy OS like Windows.
As a bonus, this is a remote-native setup, which made covid trivial to adapt to. I'm exactly as productive in the office as I am at home or on planes or in Ubers or at wine bars on sunny afternoons (modulo extra screen real estate).
Sorry, wrong term. I meant FOSS. There is some software I can justify paying big bucks for (although the list is getting increasingly shorter thanks to better and better FOSS projects). But Emacs with zero licenses at all, and being the most customizable text editor on the planet? Vim, with the most innovative and speedy keybindings? What a steal.
Don't get me wrong, JetBrains has some cool stuff. It's nice to see they're working on a lighter-weight text editor to add some competition to the newbie-friendly text editor market. And JetBrains Mono is a phenomenal monospace font.
Yeah, I know what FOSS stands for. I really, really commend JetBrains for having an open source edition. I just prefer an editor that doesn't separate features into pricing categories like Community, Ultimate, etc. I understand they have to make money as a company somehow, and that's totally fine. I just personally don't like the idea. Emacs does all I need, and more, with a single edition, and a single small fee of: zero dollars.
I like the low-power aspect of TUIs, but the problem I have with using them over GUI software is there is no launcher or start menu functionality for TUI (re)discovery. I'll often find a cool TUI posted here, install it "for later" and then proceed to forget I ever installed it. When "for later" finally comes around, I have to guess the name using tab completion or open my browser, search my history and hope it's there.
Is there such a thing as a TUI launcher out there? Something that allows fuzzy search of program names, tags and a short description (using something akin to .desktop files for the application metadata). Then, when I suddenly need a program for a certain task, I don't have to hope I memorized the correct command. I just open my TUI launcher, type something related to my task and get a list of some TUIs that could help.
I'm in the habit of keeping a text file with all software I've installed and updating it immediately. Really helps remember stuff like this.
Also I use dmenu and a script for using aliases in dmenu, and I create aliases for popping them out in new terminals. Really fast workflow.
If you're using a lot of tui stuff changing workflow from double click to launch really makes the whole experience smoother, much smoother than GUI stuff.
dmenu is great for a graphical environment. At the prompt, I've found some success with slmenu [0]. It's a dmenu clone for the command line. It works well enough that a dmenu script for a todo app works with very little changes [1]. As a launcher there's many dmenu example scripts to start from. Youtube has videos to get you started as well [2].
I do that often myself. If you've written the command before, there's also vi mode for bash history, OR, even bash-completion package for some OSes that can give arguments for simpler commands. However, I see a couple minor limitations.
1. You're limited to binaries and executable scripts in your $PATH
2. Many commands do not have bash-completion support.
vi mode for bash, bash-completion are both innovations trying to tackle this optimization of workflow. I see tools like dmenu and slmenu as better ways to give richer UI and create/reuse workflows. GP's request for `allows fuzzy search of program names, tags and a short description` is highly doable in dmenu/slmenu if not already done [0]. Not so much with bash, vi mode for bash, bash-completion.
> I'm in the habit of keeping a text file with all software I've installed and updating it immediately. Really helps remember stuff like this.
Coincidental - I just reinstalled my machine and this is the first site I came to. I keep all the applications I installed in a 'packages.new' file, and do
It's not quite the same, but I keep a similar file that notes: installed packages from the distribution repository, installed packages from AUR, enabled services, and installed extensions from programs where they can be installed from the command line. (Plus I'll note what has been removed, so I don't forgetfully install things that I've had problems with in the past.) Since everything is one item per line with few extraneous notes, it is easy to pull into Vim and modify into a script.
Properly taken notes are much more than a memory aide.
> How do you keep track when installing appimages, flatpaks, tarballs, compiling source and things like that?
Hey, I didn't claim it was exhaustively complete :-)
I have not used any appimages or flatpaks much. If I am using a program and it is not available on my new install, I'll remember to install it when I look for it.
For source compilation, it's frequently for a once-off use (maybe the repo software is too old, so I compile the latest). Mostly, when I move to a new version I don't need to recompile from source.
No, I haven't. I know there's package managers that help you keep track of what's installed, and tools that help you easily see what you've done. I just find putting a line in a text file with what I did right after I did it is less convoluted and doesn't really add to what I have to do. Automating it sounds nice in theory but actually doing it is messy and convoluted in practice.
A usual line for an install is the package name, the package type (flatpak, appimage, tarball, AUR, deb, etc) and a description of what the package is. Not much longer than the command I typed in to install.
I also keep notes on changes to the system, services created, paths changed, firewall rules, detailed notes on big things and stuff like that. Any time I run into something weird I reference it and make sure it's not something I did before I go hunting for a solution.
> Is there such a thing as a TUI launcher out there? Something that allows fuzzy search of program names, tags and a short description (using something akin to .desktop files for the application metadata). Then, when I suddenly need a program for a certain task, I don't have to hope I memorized the correct command. I just open my TUI launcher, type something related to my task and get a list of some TUIs that could help.
$ apropos -a data term
fidentify (8) - Determine file type using PhotoRec database
Pod::Text::Termcap (3perl) - Convert POD data to ASCII text with format escapes
sql (1) - execute a command on a database determined by a dburl
termcap (5) - terminal capability database
terminfo (5) - terminal capability data base
tput (1) - initialize a terminal or query terminfo database
vd (1) - a terminal utility for exploring and arranging tabular data
visidata (1) - a terminal utility for exploring and arranging tabular data
My first computer had a TUI launcher. It still does for old times’ sake actually. I found someone else’s screenshot of it running in DOSBox here: http://www.racketboy.com/forum/viewtopic.php?p=1125643 Kind of funny: it has a Y2K problem. The year is 118 in the screen shot. (99 is 1999 and 100 is 2000.) It doesn’t have the search you’re asking for. You would manually organize them yourself instead.
> Something that allows fuzzy search of program names, tags and a short description (using something akin to .desktop files for the application metadata).
What’s the problem with writing a .desktop file for a TUI app? Make the exec line open a terminal and run the app in it. If you want to open the app in place you could probably have the exec line determine the focused terminal and send a command to it to have it run the app.
Aside from the other suggestions --- having a standard "these are the tools I always install", a personal information file (served off your local system as a web page if you wish), system documentation (man, info, aprpos, or Debian's excellent and underappreciated dwww (available of course on any APT-based Debian-derived Linux variant), you could always write your own menu system to invoke or remind you of tools.
In practice, I find that there are a handful of various "swiss army knives" I return to again and again. Some of the new tools are indeed impressive, but an be implemented or offer features available in other utilities.
For myself, "apropos foo", "apt search foo", and the DDG bang "!dpkg foo" are almost always excellent starting points. Debian packages somewhere north of 70,000 individual software packages these days, and will almost always have a tool to do a specific job if not the tool you're looking for.
And yeah, the kids these days are using flatpacks and pip and nodejs and rpm (not to be confused with RPM), etc., though back in the day we had CPAN to deal with. (It still exists, of course, it's just less significant.)
In MacPorts I do ‘port installed requested’ which shows me every package I’ve installed directly, versus as a dependency. You could alias this to something more convenient. For brew I’m not sure.
A launcher could also be a "standard" middle layer that defines common key bindings for tasks that people prefer different TUI applications for (e.g. "m" --> mail - whether it's "mutt" or "mail" or "sup-mail" or "pine" behind it).
I don't use one at present, but took the short cut to define 1-letter shell aliases for some of the more common ones:
"Is there such a thing as a TUI launcher out there? Something that allows fuzzy search of program names, tags and a short description (using something akin to .desktop files for the application metadata)."
I've been looking for GUI launcher/software-catalog solution for Windows with those characteristics.
I'm not sure. It sounds like a genuinely neat idea for another TUI app though! Make the files .text too files instead and build and index of them for searching.
For anyone who wants to add graphics to their TUI, notcurses is pushing the boundaries of what's possible and viable in a terminal. Still could use some bindings for higher-level languages and ergonomics. It also degrades pretty gracefully depending on terminal capabilities.
Check out notcurses-demo and see what you can pull off in a terminal. My only gripe is that tmux degrades significantly. Regardless, dankamongmen is an awesome dude bringing back the demoscene vibes.
CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline. But TUIs are a gimmick that should have been just GUIs. (And text selection is not a reason to resort to TUIs — it’s a reason to improve GUIs.) Unfortunately native GUI programming doesn’t have the coolness/geekiness factor of TUI apps…
Edit: Looks like I should clarify – I'm not saying that people should stop creating TUIs right now: in the current landscape, TUIs do have advantages like being usable over ssh, text selection, a simpler programming model in most languages... but I'm arguing that these advantages aren't inherent to TUIs. We should aim to improve GUIs, not stuck in a interface from the 70s. Unfortunately I've seen too many people (including a big chunk of HN) that argue that TUIs are just inherently superior.
I can make a TUI by just reading from stdin, writing to stdout, and some minimal parsing and emitting of VT codes that have mostly not changed in a few decades.
To make a GUI I have to pull in megabytes of libraries, learn their API, then update them every time they release a new version that will likely have breaking changes. They'll also have questionable bindings outside of one or two "first-class" languages, so reading docs and investigating why something isn't working is harder.
Then you make your software unusable for everyone who needs to use languages other than English. For example, I can't reliably type Devanagari (the script used by Hindi, Marathi, Nepali, and a bunch of other South Asian languages) into any terminal on any operating system.
You also make your software unusable for people who use assistive software. TUIs are not accessible by default, GUIs can be with only a tiny bit of effort.
TUIs are perfectly fine for internal tooling, but any piece of software intended for general distribution should ship with a proper GUI. Even a basic Electron UI beats TUI in terms of accessibility and internationalization support.
It's not just about the IME. I'm on macOS, where it's possible to type Devanagari/Gurumukhi into both iTerm and Terminal.app without any issues.
However, neither of the emulators can render the typed text correctly. I tried typing "नमस्ते" into both just now, and they both broke in different ways.
Can foot handle this case? What about GNOME Terminal, Konsole, and Windows Terminal? If I can't reliably read Hindi text on the commonly used terminal emulators on all three major operating systems, then from my perspective a TUI app is worse in every way compared to a native GUI app or even an Electron app.
I have exactly 0 knowledge of Devanagari/Gurumukhi but I think the issue is this vertical bar that shouldn't be there when those characters are next to each other.
It's not wrong. Note that it's not a single vertical line, but a line with a smaller line below it (a halant). This has the same meaning as not having that line entirely, namely that the letter is a "half-sound" s rather than a "full-sound" sa. It's just that nobody would write it this way as part of the word namaste; it's only used when talking about the sound standalone or when the half-sound is at the end of a word. (The latter is rare in Hindi, because Hindi is less precise about denoting half-sounds at the ends of words, compared to something like Sanskrit.)
However the halant does seem to be cut too short, perhaps because it's exceeding the terminal's line height. The terminal may need to be configured to use a smaller font size for the Devnagari font. The halant renders fine in foot without having to tweak the size, but of course it depends on what font is getting used in my case vs yours.
Another problem in that picture is that the horizontal line between the n and m has a tiny break, which it shouldn't.
Right, I don't think you and OP are in conflict at all. Basically, GUIs presently suck. The average perfomance differences between TUI's and GUI's point directly to the fact that GUIs are very very bloated. There's no reason that a GUI shouldn't be as performant as a TUI, given the relative minimum it ought to take to convert one to another. A little vector here and raster support there should mostly take care of it.
Yes, but at the cost of needing to run a browser. In this modern era of everyone fetishizing single-instance applications, a browser crash caused by one tab would mean I lose not only all my open websites but also all these "apps".
I have to `pkill -9` firefox once every few days because of bugs; a few months ago it used to break the clipboard until it was restarted, these days it freezes when dragging tabs around in the tab bar, tomorrow I'm sure it'll be some new bug... I'm glad I don't lose my editor / IDE / chat clients / monitoring dashboards when this happens.
That's an argument for making GUI libraries more ergonomic, not to keep making TUIs. And TUIs made by "just printing VT codes" will break when you resize the terminal, change the font size, or more.
TUI's can deal with changes in terminal geometry, generally by redrawing. It even works in a telnet/ssh connection, the remote host gets sent that information and uses it accordingly.
Yes, it does. But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program), and you lose the aspect of 'creating TUIs are just printing VT codes'.
It's far less complexity, even still, and it has not changed much for decades. A TUI program working today will likely continue to work for decades more. If you don't care about glitz and just want to write something useful, that's a substantial draw.
> But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program)
No way dude. All you need to do is catch SIGWINCH and then ioctl/TIOCGWINSZ to get the new size. Back when I was into roguelike development, responding to the terminal resizing took scarcely more than a half dozen lines of C. I wish I knew of a GUI system this simple.
It's not redrawing/resizing with a GUI that's the matter, it's the whole of it. TUIs are easy to create without much investment in learning a whole GUI system.
That's assuming you find a TUI easier to deal with. I guess for the I-use-Arch crowd, sure, but anything more than just printing out lines of text IMO makes using VTs a pain. And if I'm just outputting text, using GTK or Qt is more than fine.
The major desktop and workstation operating systems usually have an SSH client installed by default. The same cannot be said for X11. It is easy enough to use X11 on a mobile device. You may be able to get an X client for a mobile device, but I wouldn't want to use it.
(Not to mention that some X11 software doesn't seem to work across the network these days, which causes me no end of frustration since RDP is usually fantastic. Not to mention the bandwidth requirements of graphical sessions, which is a concern over mobile networks.)
Windows doesn't have an SSH client installed by default. But I agree with your point - setting up SSH is way easier than X11 and X11 doesn't even work that well over the internet.
VNC would be a more reasonable answer but that is a pain to set up server-side on Linux and isn't very good. Really NX4 is the answer but it costs an absolute fortune.
Web UIs solve most of that - even easier to implement than TUIs and you can use them remotely.
The only big issues I have with them are security (most don't restrict connections to the same user and I wouldn't be surprised if a lot of them listen on 0.0.0.0) and launching them. There isn't a good cross-platform way to launch a browser.
Couldn't agree more. A good GUI beats a TUI any day. They have the potential to be far more intuitive as well as more aesthetically appealing. Not to mention that for some of us, a GUI gives far greater confidence than a TUI.
For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes.
I do think GUIs can learn a few tricks from TUIs. TUIs are often more responsive and usually provide better keyboard driven workflows.
Ultimately my preference for GUIs probably reflects what I'm used to. To paraphrase Jef Raskin, there are no intuitive UIs, only familiar ones.
>For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes.
cfdisk, cgdisk.
Maybe you are afraid of parted/fdisk. Then you are right.
But well, fdisk and such are a bit "nightmarish". I had more luck using OpenBSD's disklabel to slice up it's own partitions. And the GPT editor from OpenBSD (I can't remember it's name) was pretty simple to use and preview even on text mode.
You can have both good and bad CLI/TUI's, and even horrendous GUI's, such as the Red Hat installer.
One of the nice things about TUIs is the removal of visual clutter and other forms of distraction.
I also recall an article a while back about Emacs and screen readers. Since everything has to be representable as text, rather than accessibility being an afterthought, it was usable with screen readers. I imagine something similar can be said for those who need better contrast or large text, since terminal colour schemes can be defined by the user and software has to handle variable terminal sizes.
One reason GUIs aren't as cool as TUIs is ... people don't want them to be.
Growing up with TUIs, I was quite surprised how often people refuse to use a program because it doesn't conform to the "native" look and feel. I've found plenty of people who'll happily use htop in the terminal, but then complain when a GUI app doesn't respect some tiny aspect of look and feel. Even things like the placement of "Options" or "Preferences" in the "wrong" menu causes them ire.
For whatever reason, people just seem to expect different things from GUIs.
> CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline.
TUI's and GUI's can both be used in the middle of a pipe when things require some manual fiddling, Git commit would be an example of this, opening vim to edit the commit message. Here's an example (https://stackoverflow.com/questions/8371877/ncurses-and-linu...) of how you could create an ncurses TUI but still output to stdout.
> TUIs are a gimmick that should have been just GUIs.
I mostly agree. I use Midnight Commander a lot but I'd prefer a basically identical GUI version with the same keys. None of the Linux GUI orthodox file managers I looked at were comparable, though I didn't do a comprehensive search. (Edit: There are tons of GUI orthodox file managers for Linux. I was wrong.)
The main advantage of a TUI to me is that it is available over SSH more easily. X forwarding exists but I never recall it being particularly responsive.
As another commenter says, TUIs also have advantages in terms of coding.
Didn't Midnight Commander come with a GTK+ based graphical version back in the day? It was the first file manager component in GNOME before Nautilus replaced it.
In practice, for use cases where you're spelunking through different directories and running different commands: you're going to have an easier time either staying in a terminal (where opening a GUI to perform a task is awkward), or an easier time sticking with a GUI (where opening a terminal to run a command is awkward).
Currently, TUI provides many of the benefits of a GUI, without having to leave the terminal.
TUIs definitely have their place. For starters, a lot of terminal applications really don't need anything from a GUI. And GUIs carry some weight that will not be shed:
- The required libraries you need to install for them. A docker image with TUI tools can be light, with GUIs it will be heavy.
- Usability over SSH is definitely a TUI inherent advantage. X forwarding is an absolute mess, and even if someone tried to improve it probably would still be a mess. Executing code in a remote machine and sending the graphics to another system (possibly with different graphical interface or even operating system) is never going to be as responsive or integrated.
TUIs are designed to be used without a mouse and are ligtning fast. Information is condensed due to limitations to text only. By the time you open a GUI you lose or corrupt your thought process when bombarded with more visual information than the little change you wanted to make. TUIs are great for a quick in and out while GUIs are great to linger there for a while. And do some click click clicking.
Having started programming in a time where all we had were TUIs and GUIs were only accessible in expensive workstations (first computer, a Timex 2068), I also don't get this adoration for TUI and CLI.
They are a reflection of a time when I would like to have more and it was out of reach.
We used them because it was everything we had access to, that is all.
> I'm arguing that these advantages aren't inherent to TUIs.
How do you use a GUI app inline inside a screen session? And I mean _use_ it inside, not launch a floating GUI window that's disconnected from your entire workflow.
There are advantages to remaining inside the terminal, for those who are comfortable with the terminal.
I know that people love their TUIs, especially people working on tiling WM in Linux, I understand them, but I still think that the best TUIs of all time were the products developed by Borland for DOS. The Turbo Vision libraries and the apps built with them are still the gold standard in my heart.
FWIW Free Vision is basically an improved Turbo Vision for Free Pascal, it recently (as in, last month) even got unicode support[0].
Though it is a bit weird in that it uses the TP5.5-style objects which aren't as powerful as the Delphi-style objects (very roughly think class in C++ vs class in Java).
The (sadly only German) tutorial linked by the wiki has a bunch of screenshots in a terminal.
I wonder for the reason of all these list repos in the past few years. It would awesome if there was a better way to search repos. Maybe semantically in a way that you had a problem to solve and it would suggest open source projects. I think its cool to see lists of projects but I dont find it super helpful, am I supposed to bookmark 20 repos which each list another 1000 repos? There has to be a better way for discoverability.
A repo containing README.md is a primitive wiki page. And with GitHub you can contribute (pull requests) or discuss meta (issues).
But a page on Wikipedia or something like it be better. But, it's harder to create such a wiki then a GitHub repo (which most devs are already familiar with). And it might not show up as high on SEO. So GitHub repo it is.
Github still has atom feeds for repos, for example: https://github.com/rothgar/awesome-tuis/commits/master.atom Unfortunately they don't really make links to these feeds very visible in the UI anymore. But toss that in your feed reader of choice and you'll get an update when the awesome list content changes.
> It would awesome if there was a better way to search repos.
Not having that is kinda the whole value proposition of Big Data.
Github gives you free bandwidth and disk space. In return they get to "grep like a boss" running complex queries with no fuzziness; you don't.
Similar story with search engines and their crawler output. And Amazon's product catalog.
None of these let you turn off the fuzziness and run large/frequent/complex queries, even if you're willing to pay for it. Amazon's "good" product search API is ratelimited by how many convertible leads you send them.
I dunno, it's kinda lame, but I guess that's how things work.
Surprised scli isn't in there. It's one of the few pieces of software that I'll actually advocate for: super stable, great bindings if you're coming from vim, and surprisingly complete. Also since the desktop app for Signal is hot garbage, it's really a must for me.
You're a godsend. I've been trying to hack together a tiling desktop and trying to focus on CLI and tui options, the Frankenstein of graphical and tui applications is not quite what I'd prefer. And the signal electron app is 100% hot garbage, I wont use it regardless anymore. Gonna check this out.
There has been a rust-library for signal in the works. I read some discussion on it that made it clear the aim was to develop a proper signal-desktop application. The rust-library has a cli, which is not quite finished.
https://github.com/whisperfish/presage
Another option would be to bridge signal to Matrix (along with other networks as I do) and then use gomuks. It's pretty neat for TUI and can even show low Res images.I have WhatsApp, telegram and signal bridged. There's a really great ansible playbook that'll set it all up for you.
I do this because this way I can have all my chat apps in one app and also all the chart histories together in one database.
So I'm using gomuks but there seems to be no way to interactively verify, maybe I'm missing it in the docs but is there some way to verify with keys directly?
I love TUIs. They are usually clearly structured and fast. They require creators and users to focus on workflow :)
While these are experience values and not strict rules:
Astonishingly older users are performing better with TUIs than GUIs, and the worst are usually websites and web-applications. By "better" I mean fast in usage and less prone to mistakes.
The only stuff which is worse than websites are probably voice-assistants, people just avoid them. And voice assistants could be better with local evaluation and open speech database, especially for persons with limited eye-sight.
> While these are experience values and not strict rules: Astonishingly older users are performing better with TUIs than GUIs, and the worst are usually websites and web-applications. By "better" I mean fast in usage and less prone to mistakes.
The #1 thing that messes my (elderly) parents up, using a UI, is inconsistency. In modern software, this comes in two main forms: frequent updates that modify the UI, and screen-takeover notices (often about updates that have modified the UI, or to beg the user to perform an update that will modify the UI).
One of the most useful for me is McFly[1] which is not listed. McFly provides a nice U/I on top of history search. Works with both bash and zsh shells. You can remove entries from your history as well all within the McFly U/I. Game changer.
Second time I've seen this on HN, and it's also the second time I got excited thinking it has something to do with Tui, a pretty special species of bird we have in New Zealand.
What exactly is it about TUIs that make them better for somethings than GUIs? Is it just that they are simpler to use and less bloated? Would calling the direct windowing apis in each operating system be better than going through a library like GTK or QT? Is the solution better TUIs or better GUIs?
I think a big part of it, at least for advanced users, isn't only the individual tool itself, but the terminal ecosystem:
Vim, for example, excels at quick nimble edits for someone who darts around the filesystem in their terminal. Even if you have to pop back into your shell for a command or two while editing, you have the option of C-z and `fg`.
The same thing applies to many TUI tools as well. Many of them deliver things you could get with more primitive tools, as well (say `btop` and `htop` vs `ps`), but have a nicer feedback loop while still allowing for pop-in-and-pop-out interactions. GUI alternatives would have you pushing the mouse around a lot without much benefit.
That, and they work well through SSH, without the hassle of setting up X11 forwarding. For other TUI tools that are typically used in longer sessions (e.g. `gdb`), that is also a huge benefit. Most likely you won't even realize how huge until you have tried to set up a non-TUI alternative for the same scenario (the remote debugging service for Visual Studio is a nightmare to set up, for example).
As someone 2 comments down said, SSH is a big one.
I can get a TUI up and running on a remote server trivially, and at rather low performance costs. Doing the same for a GUI is a much worse experience. And when it does succeed the GUI is detached from the general interface through which I am managing that remote services (a shell session running over SSH).
IME, TUIs provide constraints to the application that help them focus on their tasks without other distractions.
TUIs are typically very responsive- you issue a command, and there's no wait. Feedback is nearly instantaneous. There are GUI apps that share this characteristic, if their authors put latency concerns as one of their primary goals, but the majority do not. Even fractions of seconds are noticeable, and make a significant impact on the usability of an application.
TUIs are keyboard driven, so I don't have to reach for a mouse for most operations, which slows down most operations, and can promote RSIs. GUIs do often have keyboard shortcuts, but they still suffer from higher latency, and generally aren't a high priority concern for the UI author, so the shortcuts tend to be inconsistent, and not usually customizable, and users typically cannot create their own.
And since there are obvious limitations, developers must focus on core functionality rather than getting paddings and margins right and be more creative in the process.
Honestly I wonder if there is a way to speed it up. Like a new terminal mode which lets you write or color a particular row/column directly, or utilizes the GPU to render to each pixel, or really anything better than literally printing text with fancy spacing, escapes, etc. on each refresh.
Until then, anything which is render-intensive you're much better using a GUI, even if it's just a shell script which opens a window while it's running.
Perfectly emulating pixel graphics with a TUI isn't really the point. The point is to simplify an interface to the most essential text. Look at lynx or elinks for an example of a more realistic and usable TUI web browser. It doesn't try to play youtube videos, it just extracts the text and content from a site to display it.
But to your question, yes there are 'text' console bitmap graphics protocols. Check out sixel for one example: https://saitoha.github.io/libsixel/ Some terminal emulators support other bitmap graphics too.
The point of things like sixel is to efficiently support interfaces where text is mixed with a little bit of graphics, like in many old-style apps of the 1980s and 1990s - they work very well for that. Replicating a full-featured GUI though is kinda outside their scope; you could make it work but it's not really the point.
As long as you don't send video/graphics, most of the terminals are limited by the link bandwidth, as opposed to rendering performance.
And if you are sending video or animated graphics, then perhaps a special video-orented protocol is a much better choice. Like that browsh project - I am fairly sure the performance would be much better with special protocol.
I love Alacritty, but when I got an M1 Mac I discovered that it was always running in x86 mode. After a couple of hours trying to figure out why… I just switched to Kitty and haven’t looked back.
I've not used it for a few months, but I installed from homebrew as well.
Run `arch` in a terminal. Does it return `arm64`?
Interestingly, I just opened Alacritty on my M1, and it's showing `arm64` now. I know it didn't before. The app has been upgraded because macOS's security tools blocked it when I tried to open it and I had to explicitly allow it.
Maybe it was an issue that they've fixed since I last looked?
The amount of these that are scriptable, that are automateable, is sadly sadly sadly low.
This feels like such a dangerous new cargo cult to me: ooh terminal good, hackers are here! Let's build applications for this! Ok, so... you may be in the console. But unless your program can be easily controlled & ran by other command line processes, unless it has machine-readable output, imo, you've simply imported the bad/ill/damaged/corrupt into a world that historically was usually much better.
Building little isolated insular worlds is what apps do. On the terminal, I expect systems to compose & interoperate well. I have yet to see a TUI toolkit/library that demonstrates any form of commitment to first-principles of the shell world. That was my comment 26 days ago, seeing Bubbletea[1], a leading Go based library. This all feels so icky, so wronghearted to me. It could be done responsibly- yes- but it's not. This feels so wildly to be missing the point of the terminal, the shell: to be a complex, interwoven system, where anything- not just some basic pre-determined rote functionality- is possible.
I think there's a lot of possible paths we could down from here. Your path sounds like a totally viable suggestion that would definitely work!
It's never quite been as easy/convenient as it should be, but services which offer a non-console but other machine-to-machine interface could suffice. Which if any of these listed examples offer HTTP or DBus interfaces for control? (Not a lot, alas, but perhaps some?) If you do want to build an application, these are good ways to make it externally controllable. I'm not aware of any dbus nor http tooling that makes interfacing with these protocols super slick & easy & friendly from the command line, but there's at least ways to do both, and we probably ought refine our script-foo in both realms.
Another thought is that the libraries/frameworks could help a lot. Ultimately frameworks like Bubbletea are ways to display stuff & script actions. Why don't we make those actions first class citizens and have the library natively expose actions in a command line format? I dont a lot of console apps do this, but a pattern I love is being able to feed a command sequence into a console program. This example is terrible, I need to think of something more purposeful, but for imagineering sake, perhaps:
To me it feels like there is distinction between cli binaries and TUI apps. They are both user interfaces, the former in a paradigm that allows composing in scripts and shell pipelines while TUIs provide a visual stateful UI.
Both have their place. Often you'll see TUI apps being built on top of their cli counterparts, in other cases both interfaces are built on top of a common library.
What you describe in your music player example is a cli interface and imho shouldn't be in the TUI binary.
I need to validate but I expect many of these tools will not handle piped input properly, use event loops or otger tools that expect keyboard input as events not just streams. Other prosaic applicationisms abound- How does one send cursor up, or F10 to get into a memu, to an app via stdin? The paradigm falls appart, & TUI's as distonctly different elements than regular cli tools rears it's ugly head.
Tools like espeak and dc that you cite fall into the conventional cli-tools camp. By compare mamy of the TUI tools we see here have their own autocomplete systems embedded in the program, multiple screens, full terminal layouts, multiple on-screen focus-able areas.
I do think GUI programs should have machine-to-machine interfaces built in too, yes.
I was young & barely knew it, but KDE's DCOP seemed like a very adequate way to script & control any app- that was awesome. Today on FreeDesktop, some apps do a good job of exposing themselves via DBus; music/media players in particular have very widespread support for the mpris interface, for example, but all sorts of apps expose control this way. The programming language Vala[1] in Gnome world has excellent DBus integration built in, so one can take some of their application models & expose them to the world, very much easing making m2m interfaces.
Ask HN: I love TUI too but usually they're designed to run inside a console. Is there a "console" I can embed in my own application so that my program doesn't need a terminal to be run ?
Of course I could use a simple GUI text widget with fixed size font, but I doubt it'd be fast...
A little late to the article, if anyone is still reading comments I recommend cmus, a console music player with extensive key bindings and library support.
Nice list.
I was hoping to find a cups printer manager TUI. Something other than the web interface that I could SSH into and view print jobs, queues, and printers.
Unfortunately there's nothing like that on the list. Any recommendations, HN folks?
I really wish there was a note taking app like OneNote with a TUI. Text only of course. With automatic syncing.
Of course you can make a bunch of text files but Easy categorisation, browsing, auto saving and even something as simple as window-size based word wrapping is difficult with most editors. Of course they're not really made for it.
Based on what you've said, you really should give org-mode a shot. (And org doesn't even have to be text only!) Given that word-wrapping is a priority for you, be sure to turn on org-indent mode and visual line mode. This gives you traditional outliner formatting with the indentation you'd traditionally expect (similar to how OneNote indents blocks) and proper word-wrapping.
Although org has a huge ecosystem (org-roam is quite good), you don't need to go beyond plain org-mode if all you want is the features and general working model of OneNote. It's basically all there, batteries included.
I'm a big fan of lazygit. I would describe myself as highly competent in using the git cli, but lazygit just makes most common operations so much faster that I'd hate to go back to only using the cli.
Same here. I still combine both, but over time used lazygit more and more. I still only use a few features: view diffs, staging and resetting files, commit and push.
One disclaimer though: I'm using version 0.14. Starting with 0.17 or so the UI got a bit too noisy (loads of colors), but most importantly the tool got extremely slow. Like the startup time jumped from not noticeable at all to several seconds, which is absolutely unusable for what I need the tool for. Since it was a real pain to downgrade I haven't tried newer versions since. Maybe it's fixed, I don't know and I have no desire to find out.
- Turn on "lynx like navigation" in "Panel options". Allows you to move around real quick when you're traversing a bunch of directories.
- SFTP/FTP mode, where you can mount a remote FS like it was local (in case you need to selectively copy files).
I’m all for TUIs but for me anything that calls itself terminal oriented needs to work at 80ish character line length. It seems that many of the entries (especially the dashboards) need much longer lines to be useful - then sorry this should be a GUI.
https://www.visidata.org/