Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reegineer terminal emulators for TUI (text user interfaces) #62

Open
abitrolly opened this issue Feb 20, 2020 · 1 comment
Open

Reegineer terminal emulators for TUI (text user interfaces) #62

abitrolly opened this issue Feb 20, 2020 · 1 comment

Comments

@abitrolly
Copy link
Member

TUIs are awesome, because they can be deterministic or atomic (I don't know - please comment) - when you can press a series of commands and it will be processed till the end with predictable results. Except that terminal emulators are not deterministic - any program can break the state of the terminal. Read on.

How terminals are killing Windows refugees?

Do you know why people are opening terminals? First execute some commands, like launching server or installing some stuff. Logout with Ctrl-D and save files with Ctrl-S. And what happens if you accidentally press Ctrl-S in Linux terminal (which by default runs bash) is that the terminal will freeze and you won't even notice that you pressed Ctrl-S by mistake.

What can be worse than freezing interface. Do you remember last time you game, phone or browser froze? Probably not so fast, or at least you know the problem - memory or slow pages. Here nothing tells you that this is by design.

Terminal emulators don't know anything about shortcuts, key down and key up

Not only terminal emulators emulate ancient pieces of hardwire, they also just transmit symbols. You don't get "events" there. No key presses, no key combinations. You also need to "emulate" them by measuring time from one letter to another to see if that's possibly a shortcut. That's why terminals are slow by definition and not atomic - instead of checking keyboard state and signalling it, they just pass chars into wire. That's why you can not use vim in NORMAL mode with Russian layout, for example. It won't be the key 'i' passed when you press a physical keyboard button, it will be char 'ш' and vim doesn't know how to process it. There is no way to read key press or release in terminal emulators. You may wonder - how does it transmit keys like Ctrl, Alt, F1 etc. It encodes them in sequences of chars. And the sequence can be different length. To know which key will it be - Esc of F1, you need again to wait. It may sound crazy, but I just realized that terminal emulators may even add artificial delays between sequences to make sure receiving side can read the difference. Slow by design, again.

Drawbacks of going from two-wire terminal model

Terminals emulators were great (and still are), because of only one awesome feature - you can run them over any two wires. One input and one output. This is how you look into boot problems with your RPi or problems with other hardware. Very awesome, but for doing a shortcut based productivity booster in console, the underlying mechanism is just wrong. If you can not make a hot seat mortal kombat game in your interface, that interfaces not a human oriented.

Why a separate TUI interface is needed

I am DevOps. Meaning I spent a lot of time in console doing thing, and I really miss shortcuts and fast response time from this interface. There are a lot of visual text mode tools like dive that really help and save a lot of time instead of remembering and typing hundreds of commands that I need almost every day. But even TUI frameworks can not fix terminal problems leading to proliferation of the frameworks, but no solution.

Where to go from here

We can have the best parts from the many worlds

  • Linux terminal
  • Windows console (https://github.com/Maximus5/ConEmu) - provided the MS won't sue people with patents
  • Browser based access control (permission to override system keys)
  • Wayland direct rendering to video memory
  • Optimize for low power consumption again
  • Game frameworks for low latency input processing and output
  • React and friends to consume resources only changes are needed (mosh as well)

It is quite exciting if we could get back to next version discrete mouseless world. Think of minecraft at your 10 fingertips in 2D.

@abitrolly
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant