Text-based user interface (TUI), also called textual user interface or terminal user interface,[clarification needed] is a retronym coined sometime after the invention of graphical user interfaces. TUIs display computer graphics in text mode. An advanced TUI may, like GUIs, use the entire screen area and accept mouse and other inputs.
From text application's point of view, a text screen (and communications with it) can belong to one of three types (here ordered in order of decreasing accessibility):
A genuine text mode display, controlled by a video adapter or the central processor itself. This is a normal condition for a locally running application on various types of personal computers and mobile devices. If not deterred by the operating system, a smart program may exploit the full power of a hardware text mode.
A text mode emulator. Examples are xterm for X Window System and win32 console (in a window mode) for Microsoft Windows. This usually supports programs which expect a real text mode display, but may run considerably slower. Certain functions of an advanced text mode, such as an own font uploading, almost certainly become unavailable.
A remote text terminal. The communication capabilities usually become reduced to a serial line or its emulation, possibly with few ioctl()s as an out-of-band channel in such cases as Telnet and Secure Shell. This is the worst case, because software restrictions hinder the use of capabilities of a remote display device.
Under Linux and other Unix-like systems, a program easily accommodates to any of the three cases because the same interface (namely, standard streams) controls the display and keyboard. Also, specialized programming libraries help to output the text in a way appropriate to the given display device and interface to it. See below for a comparison to Windows.
On ANSI-compatible terminals
American National Standards Institute (ANSI) standard ANSI X3.64 defines a standard set of escape sequences that can be used to drive terminals to create TUIs (see ANSI escape code). Escape sequences may be supported for all three cases mentioned in the above section, allowing random cursor movements and color changes.
However, not all terminals follow this standard, and many non-compatible but functionally equivalent sequences exist.
Snapshot of 'XFdrake', a TUI used in Mandriva Linux to configure the graphical system.
In Unix-like operating systems, TUIs are often constructed using the terminal control librarycurses, or ncurses, a mostly compatible library.
The advent of the curses library with Berkeley Unix created a portable and stable API for which to write TUIs. The ability to talk to various text terminal types using the same interfaces led to more widespread use of "visual" Unix programs, which occupied the entire terminal screen instead of using a simple line interface. This can be seen in text editors such as vi, mail clients such as pine or mutt, system management tools such as SMIT, SAM, FreeBSD's Sysinstall and web browsers such as lynx. Some applications, such as w3m, and older versions of pine and vi use the less-able termcap library, performing many of the functions associated with curses within the application.
In addition, the rise in popularity of Linux brought many former DOS users to a Unix-like platform, which has fostered a DOS influence in many TUIs. The program minicom, for example, is modeled after the popular DOS program Telix. Some other TUI programs, such as the Twin desktop, were ported over.
The Linux kernel supports virtual consoles, typically accessed through a Ctrl-Alt-F key combination. Up to 64 consoles may be accessed (12 via function keys), each displaying in full-screen text mode.
The free software program GNU Screen provides for managing multiple sessions inside a single TUI, and so can be thought of as being like a window manager for text-mode and command-line interfaces. Tmux can also do this.
The proprietary OS Xtext editorBBEdit includes a shell worksheet function that works as a full-screen shell window. The freeEmacs text editor can run a shell inside of one of its buffers to provide similar functionality. There are several shell implementations in Emacs, but only ansi-term is suitable for running TUI apps. The other common shell modes, shell and eshell only emulate command lines and TUI apps will complain "Terminal is not fully functional" or display a garbled interface.
OpenVMS
VAX/VMS and the later development OpenVMS had a similar facility to curses known as the Screen Management facility or SMG. This could be invoked from the command line or called from programs using the SMG$ library.
In embedded systems
Embedded system displaying menu on an LCD screen
Modern embedded systems are capable of displaying TUI on a monitor like personal computers. This functionality is usually implemented using specialized integrated circuits, modules, or using FPGA.
Video circuits or modules are usually controlled using VT100-compatible command set over UART,[citation needed] FPGA designs usually allow direct video memory access.[citation needed]
Other uses
The full screen editor of the Commodore 64 8-bit computers was advanced in its market segment for its time. Users could move the cursor over the entire screen area, entering and editing BASIC program lines, as well as direct mode commands. All Commodore 8-bit computers used the PETSCII character set, which included character glyphs suitable for making a TUI.
Apple's Macintosh Programmer's Workshop programming environment included Commando, a TUI shell. It was the inspiration for BBEdit's shell worksheet.
Later Apple II models included MouseText, a set of graphical glyphs used for making a TUI.
The Corvus Concept computer of 1982 used a function key-based text interface on a full-page pivoting display.
Another kind of TUI was the primary interface of the Oberon operating system as released in 1988Screenshot of the desktop of an Oberon System showing an image and several text viewers. In contrast to the so far mentioned uses of text user interfaces, the Oberon system did not use a console or terminal based mode but required a large bit-mapped display on which text was used as primary target for mouse clicks. Commands of the form Module.Procedure parameters ~ were activated by a middle-mouse click on Module.Procedure. Any text displayed on the screen could be edited and every command displayed in a text, which complied to the required syntax, could be clicked and executed. Any text with a bunch of commands could be used as a so-called tool text serving as a user-configurable menu. Even the output of a previous command could be edited and used as a command. This approach is radically different from the dialogue oriented command prompt and console menus described so far. Since it did not use graphical elements, but text elements, it was termed a text user interface. For a short introduction see the 2nd paragraph on p.4 of the first published report[1] on the Oberon System.
_en.png)
-console.png)
