3 ms·
I think the “in principle” is the problem. The tech isn’t the principle. The experience is. Use the right thing for for the audience. Use a GUI, use a TUI, use
by salmo 4y ago
I think the “in principle” is the problem.
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 :).
- hsn915 4y agoThe principle is the problem. 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.