Live data from Hacker News

Writing Programs with Ncurses

invisible-island.net

91–93 of 93 posts

Re: Writing Programs with Ncurses

#92
post #30

Earlier quoted context omitted.

Right. Plus responsiveness. Terminal apps have faster response time than GUIs. And when someone is typing like 10 chars per seconds it matters. The usecase is different between terminal vs GUI. Where in GUI you look - choose - decide and click. And in terminal you blindly storm on the keyboard as fast as you can.

Terminal apps are running under a GUI terminal for at least two decades now, there isn't really a reason for a GUI application to not be as responsive as a terminal application, it is just that "modern" GUI toolkits being slow. IMO a reason is because nobody seems to bat an eye when faced with a "TUI" made out of lines, boxes and garish colors but if a GUI is made like that it is suddenly ugly so toolkit developers p…

A bit of that is also related to different UX design, with many of the venerated old TUIs actually having better UX, not due to being TUI, but because they avoided certain popular (anti-)patterns of GUI programming.

A top example, from discussing with non-techies who had the tools change from TUI to GUI, is the drop-down menu bar at the top of the window (or top of the screen, for mac). What used to be few keys at worst, turned out to multiple long trips by mouse to select an option 3+ levels of nesting deep, because the job was just that complex - but there was no contextual shortcut available.

Many old TUIs (and we're talking divergent brother of S/370 with random other stuff in the mix old) tended to have ways to reach pretty deep in the navigation structure pretty fast (sometimes even direct - for example airline reservation systems, where you often can make a CLI command go straight to a completely different context).

Re: Writing Programs with Ncurses

#93
post #81
post #79

Earlier quoted context omitted.

Can you give any more guidance on what might constitute "somewhere useful"? Is the hardware cursor position the default place to start reading from?

Somewhere useful depends on the app. In an editor, it's the line of text I'm editing. In a file manager, it's the currently focused file. The hardware cursor is where it will start reading when I press read current line, word, etc.

That makes sense. It's a little harder to determine where it should go for something like a chat client where the UI changes asynchronously.
Post reply on HN