HN Explorer

Ask HN: How can we improve TUIs?

8 points by asdkhadsj ↗ HN
I've got a problem. I love Terminal UIs, or at least I love the idea of them. For the last ~10 years I've lived in the terminal, Tmux, Vim and Kakoune were my loves. Over the recent year or so, I have grown tired of the plain UI - I long for more advanced UI features. Nothing crazy complex, just UI positions not bound to character sizes, variable character sizes, better underline supports, better animations and etc.

So with wanting all of this I've largely moved out of the Terminal and into other IDEs. It's been nice, and pretty. Yet I can't help but feel the Terminal offered me so much more.

So this morning I had the thought - could the terminal be improved? Could a new terminal be written, with similar ease of development to that of a TUI, but also more advanced features? Maybe a spec that translated basic TUIs into pretty drawn screen widgets?

So I ask you: Do you think TUIs could be improved to give modern "pretty" rendering and features, while also keeping the most of the simplicity of development and interaction that we all know and love with TUIs? How would you see this done?

8 comments

[ 3.2 ms ] story [ 36.1 ms ] thread
nextos
I like classical Unix applications for non-interactive stuff.

But I feel they do not compose well for interactive things. After being a long time user of e.g. Mutt, I switched all my workflow to Emacs and I couldn't be happier.

Emacs is a great text-oriented environment. Actually, a text-oriented Lisp VM.

ksaj
Two other styles of TUI to consider: mc (which is technically a file manager, but it is a super productive one) and whiptail (which isn't a TUI either, but provides simple tools to make one.

I used whiptail to write the interface for 2 of my Raspberry Pis that have tiny screens on them. It works really well for things like that. If you've ever installed Linux, you've probably already seen it in action.

open-source-ux
A few things that would improve TUIs for me:

1. Add some left and right margins to the terminal window so the text isn't completely flush to the edge of the window. Make this the default.

2. Add a bit of line spacing between each line. Enough so that each line is spaced proportional to the height of the font and it looks pleasant. This doesn't mean acres of blank space or lack of "information density".

3. Use tables to display columnar information or data. These can be faint table lines when needed to help guide the eye across the screen. Or at least space the columns out so the data from columns don't look like they are crashing into each other. This would mean rendering a TUI with a more sophisticated display engine than a basic character-only one.

Finally, wouldn't it be nice if an experienced professional type designer applied some typographic finesse to a terminal screen? One can only imagine the disdain and sky-high snark they'd encounter from developers.

git-pull
There's a lack of financial incentive to build TUI apps. It's a niche. It's awesome for power users: no lag, all keyboard driven, raw structured data. But businesses buy slack / trello / salesforce for swathes of people. That sort of thing doesn't happen if the following is simply limited to programmers / power users (and a cross section of those at that)

I haven't seen any C++11+ wrappers for ncurses... until, recently: https://github.com/clangen/cursespp, https://github.com/Praetonus/Ncursescpp strange license.

There are people who are on the forefront of terminal tech, examples are stuff by https://github.com/saitoha, https://github.com/mitotic/graphterm

There is hyper: https://hyper.is/ It works on windows. But by then, you potentially have the lag time most terminal users want to bypass.

For windows, maybe https://github.com/microsoft/terminal will encourage more terminal innovation by bsd/linux -> windows crossovers.

On Linux, try this: https://sw.kovidgoyal.net/kitty/

I wrote a book on tmux that briefly touches terminal stuff. I still get confused when terminals are miscolored and emit junk characters. There's a lot more going on behind a terminal than meets the eye: https://en.wikipedia.org/wiki/POSIX_terminal_interface#Gener...

amirouche
I love termbox. I am writing an editor with it.
enkiv2
Were notebook interfaces (like jupyter & mathematica) not, in practice, so reliant on web-tech, they'd be a good heir to the command line / REPL lineage (in line with the mouse-aware command line that, ex., plan9 has).

On the more general TUI side, a curses frontend for TK exists (though a TK frontend for curses doesn't, AFAIK, even though it'd probably be easier to write & more complete). TK is just about the smallest, easiest-to-use, and most cross-platform GUI library, so if you want to move existing curses applications to real widgets, TK is the ideal target.

The unix terminal is a clusterfuck of technical debt, and while curses exists primarily to abstract that away, it still leaks. Basically all non-trivial TUIs are dependent upon terminal behaviors that ought not to exist anymore, and this holds back attempts at modernizing the unix terminal (like kitty at the near end and terminator at the far end), locking us into hacks like abusing control characters for indicating URLs, performing text processing in the text rendering facilities, etc.

Jtsummers
You can use Emacs' org-mode much like those notebook interfaces but for arbitrary (well, those supported by org-babel) languages. There's a learning curve and more manual configuration, but that's pretty much how I program in any interactive language (lisp, python, etc.). This mode of editing also works well for literate programming for languages you can't compile/execute blocks of on-the-fly.