Hacker News Reader

Comment by pcr910303 | Hacker News Reader

That's an argument for making GUI libraries more ergonomic, not to keep making TUIs. And TUIs made by "just printing VT codes" will break when you resize the terminal, change the font size, or more.

View on HN

TUI's can deal with changes in terminal geometry, generally by redrawing. It even works in a telnet/ssh connection, the remote host gets sent that information and uses it accordingly.

Yes, it does. But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program), and you lose the aspect of 'creating TUIs are just printing VT codes'.

Redrawing a TUI from scratch is usually trivial. Certainly far simpler than your average GUI.

It's far less complexity, even still, and it has not changed much for decades. A TUI program working today will likely continue to work for decades more. If you don't care about glitz and just want to write something useful, that's a substantial draw.

> But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program)

No way dude. All you need to do is catch SIGWINCH and then ioctl/TIOCGWINSZ to get the new size. Back when I was into roguelike development, responding to the terminal resizing took scarcely more than a half dozen lines of C. I wish I knew of a GUI system this simple.

Most GUI systems handle redrawing and resizing for you. Likewise you may need to catch some events, but that's it. Which GUI are you talking about?

It's not redrawing/resizing with a GUI that's the matter, it's the whole of it. TUIs are easy to create without much investment in learning a whole GUI system.

That's assuming you find a TUI easier to deal with. I guess for the I-use-Arch crowd, sure, but anything more than just printing out lines of text IMO makes using VTs a pain. And if I'm just outputting text, using GTK or Qt is more than fine.

Still not much complexity.

Reply on news.ycombinator.com