I fail to see how this is an argument in favor of TUIs in principle.
I fail to see how this is an argument in favor of TUIs in principle.
The tech isn’t the principle. The experience is. Use the right thing for for the audience. Use a GUI, use a TUI, use a basic CLI tool for day-to-day. And sometimes that can even be additive where more than one is the right answer.
The clicks stuff in this does feel silly to me. But I think that sometimes there’s value in not reaching for a mouse.
If you care about the tech in principle, then I think the answer is to work on a library/framework you love, like they did, vs a user app.
I’m not reinventing those wheels, and will borrow stuff like this when it seems right. And anything is better than curses :).
When your program is a TUI, it means stdout is useless. The tweet I quoted illustrates this problem. If you do both printf debugging and use a TUI debugger, you will not be able to see the output from the printf statements.
You want to draw a GUI but you're using a text stream to issue commands to the terminal to draw text and color regions of the screen - while at the same time hiding the std output buffer (and losing the ability to select and copy/paste the text being drawn).
As if drawing text and colored boxes is so fundamentally difficult it can't be done any other way.
As if handling shortcuts in a GUI program is so fundamentally difficult that it's easier to do it in a TUI.