What is the correct architecture or design to make TUI on a terminal then ? Honest question

You don't go through the TTY model, but read directly from devices (if the kernel allows it). But people will hate you for it, since it doesn't fit with the abstraction layers that are commonly used, one of which is that only characters matter, not keypresses. Consider how such a TUI that directly interacts with keyboard devices (because it wants to detect keyup events) would work over SSH. It cannot. Abstraction layers limit certain functionality, but they also allow workflows to exist that otherwise could not (or would be much more complicated). You have to judge in every instance whether the correct balance has been made, but I don't think this aspect of the Unix terminal design is awful.

I think the other problem mentioned in the article is that it has to work over SSH. TUI on a local machine has no problem hooking into input devices; display-side, the difference between GUI and TUI is just what API calls you use to render stuff. But if you want to drive things remotely, you're constrained by the remoting protocol - which, in TFAs case, is SSH without X forwarding.

Yeah, but it's the same problem. "Over ssh" means "on a terminal". Terminals have input streams, they don't have "keyboards".

Not necessarily! SSH is terminal-agnostic: It doesn't care what or even if you're running a terminal or a shell on either end.

It's perfectly reasonable to setup a pipe that sends binary data through SSH:

    cat somefile.bin | ssh someuser@somehost "cat - > /tmp/somefile.bin

That example assumes the shell of the user on the other side can execute the `cat` command but what if you didn't use a shell at all? What if you just had `/usr/bin/myprogram` as your shell? That can work too! You just need to set things up correctly (the SSH tunnel and make sure your program knows what to do when various escape sequences/signals get sent through the pipe by the SSH client--so the session can end cleanly, mostly). Going this low-level probably isn't necessary though...

For the author's original example you could write `read_raw_input.py` and then pipe it through ssh to your controlling program on the other side say, `receive_input.py`:

    /usr/bin/read_raw_input.py | ssh someuser@somehost "receive_input.py"

...as long as the two Python scripts were setup to write and read from stdout/stdin everything should work fine, be reasonably low-latency, and won't require much setup other than SSH keys.

On the other hand, if I were do to this I'd write my Python code so that it communicates with the other end directly rather than rely on the SSH daemon but that's just me (even if it was using SSH/paramiko internally).

Sure, and that'd be fine for a special-purpose app that you use for yourself, but imagine being a regular user and installing this app, and the author wants you to install something on both the client and server side, and to run ssh in this unusual way. And you have to ensure that you have the proper permissions for raw access to the keyboard on the client side.

If it's something that truly requires that sort of experience to work properly, ok, but if it's just a sort of "I want a fancy text UI that requires key-up events", this process is a bit much to ask of your users.

It seems to me that terms mostly had semi batch IO mindset. The basic unit is a chat, not a signal over time like `<sensor> down for half a second` which only make sense for high frequency or real time user interactions.

The original ttys were literally Teletypes https://www.bell-labs.com/usr/dmr/www/picture.html designed to send text directly to another Teletype over a phone line. As such they sent and received sequences of characters, not key events, yes. OFC these are also basically the same ASCII text streams that Unix pipes between shell commands and the file system.

I get the legacy aspect both in internals of the time and usage. But I'm curious how to upgrade the old way to support finer grained interactions.

That's simply not possible nor desired. It's like trying to think of a way to make ints support fractions in C without storing a second int for the denominator.

What you really want is that SSH implements support for a remote keyboard so that the application on the other end can simply read local machine key events and this is as far away from "upgrade the old way" as possible.

Good point. This reminds me of Wayland Vs xorg.

Like other's have said. If your user interface relies on key-up, it's not really possible in general. A given linux machine may only have a serial console, and afaik, you're not getting key up from any serial terminals; certainly not any common terminals. It's just not part of the design, and short of a time machine, it's unlikely to become part of the design because DEC isn't around to update the spec for vtXXX terminals or their implementations.

No, a character stream is a character stream. You don't get key down or any key events. Why does everyone talk about key up exclusively as if there were 99 supported features and key up was the only forgotten one that you need to get to 100?

There could easily have been escape sequences for released keys, just like there are for non-character keys like the arrow keys. You'll have to change your terminal emulator to support this too, though. This would work fine with SSH.

You would also need escape sequences for pressed keys.

I mean, on Unix it's ncurses, right? If no-one's ever added key-event support to ncurses then that's a(n additional) sign that it likely isn't possible and that TUIs just have to make do without the capability.

Honest answer: one that doesn't involve the need to capture individual keypresses. It just doesn't work on a Unix tty. Use a web app or other smart client (c.f. the IBM 3270, which had this problem largely solved in 1971 by putting the key navigation intelligence into the terminal).

I was about to say that, distributing real time input processing near the terminal makes sense. Also I wonder how video games handle that separation.

You're not supposed to write very advanced TUIs (advanced being subjective here). It's not what the interfaces were designed for.

The interfaces for advanced UIs is Wayland and X. TUIs are meant for compatibility, not fancy ability.

Right. And on top of that, one of the useful benefits of a TUI is that you can use them while ssh'd into a remote server. If your fancy TUI is expecting to get raw access to the keyboard, it's not going to work in a ssh session.

Who says? Actual question.

> TUIs are meant for compatibility

Nonsense. Our machines don't even get GUIs installed.

That's exactly what the compatibility is for. Tools that work in the absence of anything advanced, with nothing but a few escape codes to "draw".

Otherwise it wouldn't work on the kernel console (the only thing available without a GUI installed), over SSH, over serial links, even still on dedicated terminals and teletypes.

Terminal is still a first-class UI mode, not some fallback.

If some tooling doesn't work for us (which means over a terminal), then we don't consider it. If something doesn't expose functionality over a terminal, that functionality doesn't exist.

Sure, it's a first class UI mode from the 70's, which is extremely useful. Any development of it would be in direct conflict with its qualities.

> If some tooling doesn't work for us (which means over a terminal), then we don't consider it.

Who is "we"? Even the most die-hard TUI fan uses them through a GUI terminal emulator, making that argument fall entirely apart.

Correct architecture for terminal applications is command line; line oriented input, line oriented output. Not handling individual key events.

Even back in the 1980s, when I was asked to reimplement the heirarchical DEC VMS "help" command for SunOS (in a terminal window), it was necessary to handle individual characters rather than use line-oriented input. The VMS "help" command had been written for VT100/VT200 terminals and their cousins, and was designed to take action on a single key press, rather than waiting for a return/enter action to "send" the command.

Not always, mind; having to press enter after every character press in vim would be a major drag!

ed/ex works perfectly fine with only line input and output. Afaik TECO stared out like that too.

Gvim works for visual editing

You can read individual characters just fine from a command line app. That's what tty "raw" mode does.

We need a text-mode equivalent of X11 (and then ssh forwarding for it).

To add, you can read the kb events even in a command line program. Using GUI APIs works fine in terminal programs if the GUI is running. Works even remotely in a GUI that support network transparency, like X does. Eg like this:

https://stackoverflow.com/a/4037579

> Linux exposes your keyboards as /dev/inputN devices

Yeah, but those are only readable by root.

The modern Linux stack allows non-root users to access these if they're "bound" to the right 'seat' and 'session' in the freedesktop-derived multiseat infrastructure. AIUI, this is how non-root X works as well. It's incredibly clunky stuff because no one has ever made the effort to refactor it nicely (the typical problem with all fd.o stuff), but this is supposed to be possible.

this comment was an excellent read. is there any kind of book that covers the historical development of computer tech in this way, that isn't just a full-blown technical reference?

Not at that level of completeness, no. Most people who puzzle this out start with writing escape characters in shell to dazzle up their bash prompts and then escalate from there to figuring out the rest of the protocol.