undefined

points

[-]

>I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad.

You'd think that, but you'd be wrong. Case in point from Emacs/Vim and the Borland IDEs to Claude, plus all kinds of handy utils from mc and htop to mutt.

>They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely

That's not necessarily bad. Not everything has to be open ended.

by utilize180820 minutes ago|

parent|

[-]

How many developers are using VSCode? How does that number compare with Emacs/Vim?

In many ways, GUI was developed as the natural evolution of TUI. X server, with its client-server architecture, is meant to allow you to interact with remote sessions via "casted" GUI rather than a terminal.

Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.

TUI just got the nostalgia "coolness".

by chrysoprace1 hours ago|

prev|

[-]

Here's why I use them: many modern graphical applications are extremely wasteful. TUIs are typically small, low footprint applications that don't come bundled with a browser or webview. I don't need yet another electron app for every little thing.

by dale_glass3 hours ago|

prev|

[-]

I disagree, I think TUIs are a great fit in some problem domains.

Think for instance the Debian package configuration dialogs -- they're far more comfortable than the same questions without a TUI, and still work over a serial console if you have to use one.

For tools like various kinds of "top", there's many potential tools you can use to the same end and intentionally using one that draws CPU graphs over one that just displays a number. Graphs are much easier to interpret than a column of numbers.

In many cases they're the optimal choice given some constraint -- like the desire to have minimal dependencies, working over SSH, and being usable without breaking the flow. Yeah, you could make a tunnel to a tool that runs a local webserver and delivers graphs by HTTP, but the ergonomics of that are terrible.

by dwb2 hours ago|

parent|

[-]

Sure, I said I understand why people build them. I’ve used a lot of them. And yes with the tools we have you’re right, but I’m more lamenting the wonky, kind of archaic, unintegrated, only-semi-composable toolset that we have. No fundamental reason why you couldn’t deliver more structured UIs directly over SSH or a serial console, it’s just that in this timeline that didn’t happen yet (apart from X forwarding, which isn’t quite what I’m on about).

by fragmede52 minutes ago|

parent|

[-]

Yes. Composable GUI is what we're after.

by danudey52 minutes ago|

parent|

prev|

[-]

The difference there, in Debian's case at least, is that there is a distinction between the frontend and the configuration backend; you're probably most familiar with the `newt` frontend, but there's also `text` (for textual entry without using curses or anything), `noninteractive` (for just use the defaults), gnome, kde, teletype, or even 'web' which does not seem to work effectively but is a neat idea regardless.

TUIs which are just TUI views of data you can get otherwise are fine; TUIs which are the only way to interact with something... less so.

by worldsayshi1 hours ago|

prev|

[-]

I think I see your point. I've had it in the back of my head too.

Guess it's like the separation between backend and front-end. When the logic is neatly wrapped in a nice API you can potentially get a lot of reusability from that since the API can be integrated into other things with other use cases.

But a TUI probably doesn't naturally come with a separate backend. However, if a cli is built in a non TUI way it is about as flexible as a backend. Output can be streamed into pipes etc.

I can't stream k9s output into a pipe or variable but I can with kubectl.

Would be nice if we could have the cake and eat it here. Can TUI frameworks encourage having it both ways?

by elevation3 hours ago|

prev|

[-]

Yes, but this kind of dashboard was never going to be accessible anyway. It's a dense visual representation of vast system state with constant real-time fluctuation. Even in a browser, it would be hell to navigate the constantly changing state with a screen reader. And visually increasing the scale and contrast defeats the purpose of the density of the original display.

If you need to support screen readers, your UI would have to be totally different: You should allow the user to snapshot the system state and navigate it. Generate succinct summary text to impart the same sense that a dashboard would to a visual user. "Normal: All systems OK" "Critical: Boeing RPA servers down since 2:17PM PDT and 54 others". Once you've done this work, a CLI tool could expose this just as screen-readable:

    $ cli status
      all systems OK, last outage resolved 2:27 PDT

    $ cli topjob cpu
      117 Boeing RPA, 78% CPU
      434 SAIC PDM, 43% CPU

    $ cli downtime today 117
      Boeing RPA down 10 minutes today, resolved now

by dwb2 hours ago|

parent|

[-]

I’m not just talking about screen readers, though they are important. I mean “accessible” more generally. Yes you could build a specific UI for each kind of user, but that seems far less likely to cover as many uses as building one UI that is structured, programmatically navigable, etc.

by fxtentacle2 hours ago|

prev|

[-]

Maybe we just need to go all the way: How about a WASM core with a React GUI that runs inside a custom Electron renderer which outputs the TUI? 100% CPU guaranteed. And you'll never find that important piece of information in an all-monochrome wall of text with no icons. Why use a low-level print() when you could improve your productivity with a high-level framework? /s

by dwb1 hours ago|

parent|

[-]

Did you reply to the correct post? Can’t see how it follows from mine.