Hacker News Reader

Comment by rollcat | Hacker News Reader

I've said it before and I will say it every chance I get: TUIs are poorly disguised GUIs, and the whole premise of TFA seems to be here to support this notion.

If you want to integrate your TUI program more tightly with the terminal emulator it's running in, how about you rip out those half a dozen layers of abstraction and indirection and compatibility with half-a-century-old hardware that nobody produces anymore, that sit in between your program's display logic and the actual pixels on the screen? You can keep the grid-of-characters display style, but e.g.:

- implement text selection that works in sub-frames

- give your program an icon

- support key combos like Ctrl+Shift+F

- display an inline picture

...all while removing hundreds, probably thousands of lines of code.

View on HN

TUIs have conventions that grant them high usability and accessibility.

GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions.

That said, yes, without a doubt you can make a GUI that is as usable as a random TUI. You can even make it work well over ssh. And even get shorter code after it's done. You will just have a hard time communicating you did that to people.

> GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions.

Yes, that's unfortunately the status quo. TUI's main saving graces, and the reason why it's actually a popular choice for modern apps, are:

- It works everywhere (once you solve the portability quirks, which are present both at OS level and on each different terminal emulator)

- The API is simple and stupid (paint a character here)

- There's only this many things you can do, so you don't over-engineer your UI

- Accessibility. Screen readers are guaranteed to work (but lack a11y context)

I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage. htop or ranger are actually pretty good apps, just wish they weren't chained to an emulator.

> I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage.

The baggage may be unnecessary, but I think the key to the success of TUIs is that the terminal’s interaction mechanism is restrictive. To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of. You might end up with something better, but I think it will be very reminiscent of current terminal emulators.

I think my ideal terminal emulator would be HTML based. Programs would output HTML, with some special extra tags. If you want a UI, serve a web interface on a random port and embed it in an iframe.

You could make app launchers with links that run other apps, and even non terminal people would want to use it.

I think that’s more or less what this project is working towards:

https://hyper.is

> To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of.

I like to think that software developers are very smart people, and only need a little nudge to steer in the right direction. If all you have is PutRune(x,y,r) and intentionally omit PutPixel(x,y,p), you'll indeed just make a worse terminal emulator.

Any decent UI toolkit focuses on a high-level description of the user interface (that's how you get a11y, basic keyboard navigation, etc almost for free), and only provides the low-level operations as escape hatches. This has to be the default route, even for complex or highly customized interfaces (spreadsheet, DAW, etc).

I think our nudge could be direct support for terminals as a fallback rendering backend. Best of both worlds: you get a well-behaved GUI app, that you can also use over a serial console (with gradual loss of functionality) if things get dire.

> Accessibility. Screen readers are guaranteed to work

I wonder how useful screen readers are in curses-style applications (I don't have any experience with screen readers)? Sure, it can probably read it, but applications like this is essentially just a screenful soup of character blocks. It sounds like it'd make for a very tedious screen reading experience.

Correct. There's no additional context for the reader. There's blind people who are pretty good at Nethack. Once you're stuck with a character soup you might as well fully embrace it.

All those points equally apply to web apps and that’s exactly why web apps are becoming the default starting point for any new product.

What kind of high accessibility is there in a conext-free alphabet soup?

High usability is also illustrated by the original post - you can't even switch to a TUI app properly!

How would you make the GUI work well over SSH, unless you mean having the GUI installed on the client device and only connecting to the host over SSH?

A huge part of why I keep my workflow 100% terminal / TUI is because I know I can use anything with a solid shell (even my iPad or my phone) and instantly have my full workflow exactly where I left off with every single program looking and working exactly the same in exactly the same state.

TUIs have one property I really like. They work over SSH.

Of course, so does a web app with port forwarding, or ssh -X with a bit of a bandwidth hit.

Reply on news.ycombinator.com