[hunter2_]

TUI stands for "Text User Interface" not "Terminal User Interface" considering that the point of TUI vs GUI is to distinguish text mode from graphical mode. The word "terminal" isn't really meant to imply text even if quite a few terminal emulators are, indeed, text mode; rather it typically means that the UI is drawn by some other machine than the one you're touching. For example, a very popular Windows Server feature formerly named "Terminal Services" is for GUI terminals, not TUI terminals. A likely source of confusion is the MacOS app named Terminal, which only becomes a terminal in the real sense of the word once you decide to let some other machine draw your UI (ssh, telnet, rlogin, etc.).

But it looks very cool!

[hombre_fatal]

TUI also means terminal user interface.

But this is wrong:

> it typically means that the UI is drawn by some other machine than the one you're touching

I guess you're conflating thin-client terminal in the networking sense vs vt100 hardware terminal lineage (where "terminal" comes from here), but it means a text mode interface that runs in the terminal emulator and uses, say, ansi escape sequences.

Rather, when you see TUI, it just means the app runs in one of your kitty panes.

Btw, your "Terminal Services" example doesn't show that "terminal" implies remote drawing. It shows Microsoft extended the word to cover remote GUI sessions, which is a later, broader usage.

[fc417fc802]

> Btw, your "Terminal Services" example doesn't show that "terminal" implies remote drawing. It shows Microsoft extended the word to cover remote GUI sessions, which is a later, broader usage.

They didn't. It implies remote drawing and that has at least occasionally included arbitrary graphics. See plan 9 for example.

[hunter2_]

> I guess you're conflating thin-client terminal in the networking sense vs vt100 hardware terminal lineage

Yes, I didn't really think to separate the two. While my examples of ssh/telnet/rlogin are all of the networking variety, I didn't mean to exclude RS-232 (which the VT100 used). Regardless of whether the wire is for serial or packet data, if you're at a terminal (including any of the thin/dumb/smart varieties), you're not at the box doing the heavy lifting because that's on the other end of a wire representing an important demarcation, a demarcation that doesn't really apply to a local app running a text-mode user interface (or if the mental gymnastics are performed that does introduce such demarcation even within a local app -- think backend vs frontend -- then all local apps are terminals).

[joshka]

Historically, “TUI” referred to “Text User Interface”, but language evolves and “Terminal User Interface” has been common usage in terminal-app/tooling communities for at least the last decade (probably more).

The distinction we (Ratatui) draw is that the rendering surface is a terminal: historically sometimes a physical hardware terminal (someone got Ratatui running on a Minitel a while back), more commonly today a terminal emulator/PTY environment.

That framing also better captures the kinds of constraints and capabilities Ratatui apps actually deal with: terminal escape sequences, cell-based rendering, alternate screen buffers, mouse handling, resize behavior, scrollback interaction, etc.

In addition, these apps don't only do text only these days as modern terminals support various graphics protocols (Sixel, Kitty, iTerm graphics) and other extensions that can allow for weird and wonderful things that are not just text.

[hunter2_]

Thanks! As I think about terminals in quite different contexts (credit card terminal, battery terminal, train terminal, etc.) I'm realizing that it's really just any kind of endpoint at all, so pretty much any human interface device (HID) should probably be called a terminal. But when taken to that level, using the acronym TUI (in the "terminal" sense) to mean "not a GUI/CLI" (as if big old consoles or emulators/PTYs thereof are the only type of terminals) seems questionable.

[wolvoleo]

Sixels are far from modern :) They were introduced in the VT240 (special purpose version of the 220) and became mainstream on DEC terminals with the 320.

[_flux]

On the other hand, there are many elements in the user interface that are not text. In fact, I think it would be quite understandable if one even separated REPLs like bash or octave to be "text user interfaces" while applications that make use of character placement and border special characters "terminal user interfaces", because they use means beyond text stream to communicate with the user. One might even render straight up graphics to a terminal [emulator application].

Even X had a separate application called xterm 42 years ago: the complete X system was not to my knowledge called a terminal system, except perhaps when discussing the dedicated client devices, such as VT1300. Also the term "virtual terminal" as far as I know has always referred to a the kind of interface this application is making use of.

So I think we can just accept that the term is overloaded such that "terminal" refers to both of these situations, as there is no historical precedent to have it exclude the other situation, and the term "terminal-based application" is completely clear to a rational listener.

[wjholden]

Moreover, I'll appeal to authority and point out that Ratatui's motto is "Cook up delicious terminal user interfaces" (https://ratatui.rs).

[mentalgear]

Doesn't make it in any form a valid argument for Terminal instead of Text.

[rustyminnow]

> character placement and border special characters

These characters _are_ text though. They can be copy pasted like text, I can use them in my text editor, you can stick em in a string.

[nine_k]

A REPL like bash already is not a pure text stream, since readline is used. Zsh, even less so.

[_flux]

But they are just convenience features, not in my opinion the defining property. They basically work just the same without them.

[nine_k]

Try running plain sh / ash interactively without readline, and notice how much pain it is.

But I agree that having multiple windows, etc is a whole new step; it's just a limited GUI accessible easily via SSH. Could involve sixel graphics as well.

[_flux]

Virtual terminal is surprisingly capable, it even has word delete feature! And shells have some nice history features which I'm sure would become even more familiar if one had to use them (as I suppose was the case a long time ago), such as !$ that expands to the last argument of previous entry.

[dual_dingo]

I would argue that a local only session with terminal.app is still a real terminal session because the app is just a terminal for the connection to the MacOS version of getty. In principle, this is not different from having a serial cable between the host and an old-style terminal or encapsulating that connection over a different network like with SSH and telnet etc.

[embedding-shape]

macOS also call their log viewer "Console" for what I'm sure are obvious reasons to some, but seemingly confuses every beginner developer at least initially, while "console" is what many have come to understand "Text-like entry system to run computer commands".

[skydhash]

Unix has a dedicated console concept which is the system output. This is more likely to be the hardware console (and maybe synonyms). I think there’s a lot of steps to get to a log viewer named console, though.

[mentalgear]

Very much agree - "Text User Interface" is also a much clearer descriptor for non-technical users to understand. Normal people have an immediate idea of 'text' but not of that 'strange nerdy terminal thing' - and that's important because often times a good 'Text User Interface' is all that even regular people need !

(plus custom theme customize-able & much less work for the devs to build & maintain, and way less dependencies)

[gcgbarbosa]

If it is just an acronym, they can define it as they wish in my opinion.

As long as they defines it first (and they did)