It's a TUI if it uses text to build those elements.
You can be effective and powerful in any kind of interface, Just like you can be ineffective and weak in any kind of interface. People like TUIs because they're cool, and work over SSH.
You can be effective and powerful in any kind of interface, Just like you can be ineffective and weak in any kind of interface. People like TUIs because they're cool, and work over SSH.
What do you mean by this? I have never heard these terms before. I can launch and interact with a GUI from a text application, or a text application from a GUI.
Beyond this, without remote X properly configured, again, most don't and probably shouldn't.. you aren't running remote gui applications over an SSH session. Richer TUIs were pretty common in ye old days of DOS and other OSes before rich GUIs become the norm. DOSShell, Edit.com, etc. The IDEs of days past and Word Perfect even. These all interacted with Mice and were considered the norm. The features that allow this over a remote terminal today are pretty great IMO, the harder part is properly handling window sizes/resizes, etc.
With graphical extensions, there are even nice app explorers with image previews via TUI. It pushes the boundaries. For that matter, I often wonder what could have come with RIPscrip/RIPTerm if the leap to web didn't happen the way it did...
I think the single hardest part of TUI is dealing with wide characters and secondary fonts for color emojii that don't quite render in 2 spaces completely in a lot of termianls... it makes the line drawing harder too.
A terminal is an OS construct mostly. It will, with permissions, allow you to do anything the OS can do, including shutdown, or serve more data. It's the default mode of operating the system.
The opposite is not true. The default mode of operating a web browser will not let you create a terminal access or do anything new with the machine.
Insofar as the previous is false - because it website has flaws that allow code execution, shell escapes, or remote package installations, it's worth pointing out that these are usually possible because your web server is running as a user on a system, effectively with system access via similar interfaces as the shell.
This is like saying you can operate a car from the truck - yeah maybe through some weird gymnastics, but the trunk is for transfer, and the drivers seat is for operating.
You're off base with your talk of terminals being "OS constructs" or whatever, I think it's because you're not being precise with what exactly you're talking about. "The terminal" is a combination of a terminal emulator, which is a userspace program which interprets control sequences that tell it which characters to render where. The terminal emulator is connected to a psuedoterminal, which is a pair of files for IPC with some special semantics, notably canonical mode. Importantly, in none of this is anything for controlling the system.
For controlling the system, you need some other program besides a terminal. A shell. A shell isn't part of the terminal, nor part of the operating system except in a broader sense of the term. And it doesn't have special abilities to control the system, anything the shell can do, a TUI or web interface, or any other kind of interface can be made to do.
Anyway, you ssh into a computer and start a TUI. The TUI doesn't render anything, it just sends you text and escape codes. The terminal emulator on your computer interprets this stream of escape codes and text, as a web browser interprets html, and renders it locally.
Text interfaces and text based sessions have a definition, as do graphical interfaces, as does web interfaces. They're separate and well defined even if there's some minor blurring at the edges or you can emulate one inside another.
With a web app, you can slice and dice processing between local and remote by running JS locally. Most processing usually happens remotely though, and only the display and command logic is run in the browser.
It's not a matter of if you can do much as if it's practical, reasonable or worth the effort. I say this while writing an application that is effectively a remote web GUI over what can be done in their terminal sessions, because I want a nice UX.
I'm hoping to sell it commercially even. That doesn't mean TUI can't be a better option.
You can definitely connect aWeb.UI to a remote system and over web sockets be really close to immediate. Though you're still interactive with disconnected state.
It's not usually an issue. That said, there is a lot more complexity and room for bugs for some use cases over a terminal session and plain text or TUI applications.
I've built a career on handling the complexities of web based applications over the past 3 decades. It's far from a panacea.
Is it pixel or vector mapped, designed to run in a graphics terminal? GUI.
Of course strictly speaking TUI is a subset of possible graphical user interfaces, but the term GUI was coined to denote interfaces other than the already-ubiquitous text terminal interfaces.
TUIs have since absorbed GUI interface elements like buttons, checkboxes, and even pointer input, which I think is causing the terminology complaint here. Classical TUIs like Norton Commander are more about keyboard input and navigation. But being text-mapped is the identifying feature of a TUI, I think most people accept.
My point is that it’s not a given that having one means you have the other.
TUIs are wonderful for the first case.
Your terminal windows (whether that's "Terminal" or "cmd.exe" or anything else) are still fundamentally graphical programs that emulate such a text session.
- https://en.wikipedia.org/wiki/Linux_console - https://en.wikipedia.org/wiki/Windowing_system#Display_serve...
No. All you've done is make a low-resolution GUI.
A GUI that is built with Text, and intended to be used in a Terminal, is what a TUI is, colloquially AND definitionally.
What do you think qualifies as a TUI?
The issue is not the text. It's the WIMP interface.
Of course you can use the primitives of TUI, especially with mouse support, to reproduce a large amount (if not all) of the standard GUI interaction paradigms.
But it's bizarre, and missing the point from a UX perspective.
As an extreme example, we can imagine a program that displays the borders of a 40x15 "window" in the middle of a console, with box-drawing characters, putting a "close box" in an upper corner, with text like "File Edit Help" in the top left. We can imagine it responding to a click on the "File" text by popping out a "menu"; we can imagine a drag starting from the "title bar" causing the window position to be update (and the entire terminal window redrawn).
A lot of those kinds of functions, ironically enough, might make sense for a TUI editor implemented as a TUI (except the "windows" might just be understood as panels where the ultimate program displays parts of its output). But as an emulation of GUI windows, it'd be a strange, impractical novelty.
Even in your example, it's pretty clear cut. If the window is built with text and served in a terminal emulator, it's a TUI. If you build it with a graphical framework that now needs X11 or whatever, it's a GUI.
This is just needlessly pedantic.
It's a GUI that works over SSH. There is a very valid use case for that.
But if this thing requires you to just tab a lot through lots of pointless and rarely used fields to get to a "button" so you can activate it, because it's really all designed to be used with a mouse, then it's a bad text-based UI.
There are some incredibly good text-based UIs around, some going back to mainframe stuff from the 70s. Most of them are optimised for speed of control via keyboard rather than for looking pretty. Almost none of them would be quicker to use with a mouse.
How about those text games that used ASCII art and you typed in commands like "look" and "go north"?
I would say using text mode is the primary requirement for a TUI. The other requirement being some kind of human-machine connection, IE a User Interface.