5 ms·

I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatte

by dwb 8mo ago

I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. 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. I get why people build TUIs, but it’s a sorry state of affairs.

dale_glass 8mo ago
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.
- dwb 8mo ago
  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).
  - fragmede 8mo ago
    Yes. Composable GUI is what we're after.
    - dwb 8mo ago
      Yes!
  - dwb 8mo ago
    I found this which is by far the closet to what I’m on about. Imagine this but with inline UI controls too (keyboard-controllable, natch), probably based on Nushell (I like Nushell), and maybe an “alternate display mode” type thing for UIs that want to take over more and not act as a transcript. And, no offence, but more visually appealing and implemented with a common-denominator subset of native UI controls where possible. Clearly the issue is not building it, but adoption. I don’t have an answer for that. https://github.com/unconed/TermKit https://github.com/unconed/TermKit
- danudey 8mo ago
  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.
  - skydhash 8mo ago
    I like TUIs, but if given the choice between a TUI or a CLI program, I'd take the latter. You can always create your own interface from it. Better if it's backed by a library.
elevation 8mo ago
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
- dwb 8mo ago
  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.
fxtentacle 8mo ago
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
- dwb 8mo ago
  Did you reply to the correct post? Can’t see how it follows from mine.
chrysoprace 8mo ago
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.
- dwb 8mo ago
  I’m definitely not advocating more little electron apps, and I’m totally with you on TUI’s benefits. I’m bemoaning the lack of imagination that has ended us up here and not in a situation where we can have, say, a small, low-footprint application that can deliver a more structured UI with minimal dependencies. It’s not an impossibility, it’s not even that difficult to imagine, we just don’t have the exact technology.
  - flomo 8mo ago
    I'm with you. The thing is Windows 98 let you throw up a HTML window with almost zero overhead (the OS used the same libraries) and javascript could get data easily from another process via COM etc. Now like 25 years later, apparently our choices are shipping bespoke copies of Chrome and Node, OR making shit work on an emulated 1981 DEC terminal. Lack of vision is exactly right.
  - exceptione 8mo ago
    We do. We are only stubborn. Cross platform and low-footprint: .net core => avalonia ui Java => JavaFX
  - chrysoprace 8mo ago
    I think for the time being, there's no way to get around writing native UIs to get a native experience. Any sufficiently high level APIs will have to give up something. TUIs for me fill that niche because across any POSIX-compatible interface they will generally work the same, and modern high level languages make cross-compiling to terminals a breeze. Now to write a native UI across Windows, MacOS, Wayland and X11, that's a different story.
    - 8mo ago
worldsayshi 8mo ago
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?
coldtea 8mo ago
>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.
- utilize1808 8mo ago
  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".
  - jazzyb 8mo ago
    > How many developers are using VSCode? How does that number compare with Emacs/Vim? Perhaps I'm in some sort of "TUI bubble", but I'd bet good money that Emacs/Vim users outnumber VSCode users by an order of magnitude. But maybe I'm just surrounded by *nix devs.
    - chrisweekly 8mo ago
      I'll take that bet
    - 9dev 8mo ago
      No need to guess, the SO survey is probably still representative of the state of development environments: https://survey.stackoverflow.co/2025/technology#1-dev-id-es https://survey.stackoverflow.co/2025/technology#1-dev-id-es Note that respondents may use multiple tools, but around 76% answered VSCode, whereas 24% answered Vim. So, I’d wager you’re indeed in a *nix bubble.
quotemstr 8mo ago
They are GUIs --- just minecraft GUIs. One day, we will rediscover why GUI toolkits exist. The only real advantage TUIs have over GUIs is easy remoting, TBH. Maybe that's enough for people. Otherwise? They're just hair shirts.
- jxdxbx 8mo ago
  I've use Claude to make myself a number of little tools and weird apps that only I would want lately. They need to be cross-platform between Linux and Mac and sometimes Windows. The best approaches I've found are Tauri (+Svelte for making layout easier) for lightweight GUIs but for anything more complex I prefer a TUI. The Ratatui framework works very well. A TUI feels like a "real" app as opposed to a glorified webpage. For actually serious software I'd want a native GUI on each platform.
  - quotemstr 8mo ago
    > A TUI feels like a "real" app as opposed to a glorified webpage. Huh? "Feels"? Plenty of Electron/Tauri apps feel perfectly normal. Like I've been saying, the TUI craze is just a fad.
    - jxdxbx 8mo ago
      A TUI app feels like a native terminal app like I have used for my entire computing life, in DOS and then Linux. Electron apps feel like web apps no matter how good they are. I stopped using 1Password when it became an Electron app and became super janky. Discord, Slack, VS Code, the Signal desktop app, all suck UI-wise compared to actual native Mac apps, which even with Liquid Ass, are still better than using web technology for desktop apps. I know that lowest common denominator cross platform apps make economic sense to develop, whatever. They still suck to use.
      - quotemstr 8mo ago
        Again this word "feels". Is it not just nostalgia?
worthless-trash 8mo ago
> They flatten the structure of a UI under a character stream Isn't this ... everything though? Even the browser which you mention as better in the next paragraph.
- dwb 8mo ago
  No. The browser structures the page in both a DOM tree and an accessibility tree.
  - worthless-trash 8mo ago
    What.. no, its text.. I've seen it in view source.. You're talking about yet another 'presented' data stream, which is different than the character stream. One can rebuild these at will, im sure.
    - dwb 8mo ago
      The source of a web page is parsed to form DOM and accessibility trees. The character stream of a TUI can’t be parsed into anything similar because it is not given in a formal language that can express those structures.
      - worthless-trash 8mo ago
        We're going to have to disagree, if you consider the 'browser page' as the interface, it falls into the same problem you see with TUI's... you must reach into the DOM and accessibility information not via the character stream but with an API, the TUI has the same issue. You've given me some great points to think about, thank you for the engaging conversation.
consp 8mo ago
> You’re forced to use it exactly the way it was designed and no different So ... Like all Apple products?
- dwb 8mo ago
  Not even close. Apple UIs - despite recent graphical howlers - have excellent accessibility APIs and are regularly praised by people that track such things. I’ve recently been building a macOS app and the UI testing is also based off it. There are apps that allow full keyboard navigation using it. I do agree that the window management side is much less customisable, though, and that does frustrate me.
simgt 8mo ago
What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore. I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.
- dwb 8mo ago
  I agree about the constraints. My ideal solution would also impose harsh constraints, but would also add just enough structure. I’m also frustrated by each app reinventing the same thing slightly differently.
- fyredge 8mo ago
  I don't quite agree with this. Feature discovery is much easier in GUI when most commonly used features are either in the first layer of menu or in standard hotkeys. In the worst case, you would do a search in GUIs that provide them. In CLI / TUI, no such function is present and you would basically have to man and scroll through all possible commands to find it, though I guess grep helps.
  - 1718627440 8mo ago
    You accept search in GUI, but don't in man pages? Scrolling through actions in a tree-like menu structure is ok, but through a tree-like structure in the --help output is not? Feels inconsistent. The whole benefit of text-based interface is that search, filter and transformation is always available and completely independent of the running program. I can see the visual discoverability aspect for GUIs, but for the visual layout GUIs and TUIs are on par, the difference is rather in the rendering mechanism: pixel vs. character-based.
    - wredcoll 8mo ago
      >The whole benefit of text-based interface is that search, filter and transformation is always available That's the point about TUIs, they remove this benefit. You can't (practically) grep the output of btop or vim or whatever.
basilikum 8mo ago
I like that they are integrated into the terminal and stay in the terminal. For most things my terminal multiplexer is essentially my tiling window manager and everything that breaks out of that via its own window is very unergonomic and breaks the structured logic of my workflow. Technically just having a full GUI inside the boundaries of a terminal would be fine for a lot of things. But it's also one of these things where constraints make a lot of things better. Many GUIs are just really bloated and bad. TUIs just do not allow a lot of the sins of modern GUIs. I agree that they can get very clunky for non text based tasks or anything where you actually need custom text formating.
- dwb 8mo ago
  Yeah, I sympathise. This is another angle on the sorry state of affairs we find ourselves in.
JCattheATM 8mo ago
I don't think most GUIs expose any more structure than TUIs.

by dwb 8mo ago

dale_glass 8mo ago

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.

dwb 8mo ago
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).
- fragmede 8mo ago
  Yes. Composable GUI is what we're after.
  - dwb 8mo ago
    Yes!
- dwb 8mo ago
  I found this which is by far the closet to what I’m on about. Imagine this but with inline UI controls too (keyboard-controllable, natch), probably based on Nushell (I like Nushell), and maybe an “alternate display mode” type thing for UIs that want to take over more and not act as a transcript. And, no offence, but more visually appealing and implemented with a common-denominator subset of native UI controls where possible. Clearly the issue is not building it, but adoption. I don’t have an answer for that. https://github.com/unconed/TermKit https://github.com/unconed/TermKit
danudey 8mo ago
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.
- skydhash 8mo ago
  I like TUIs, but if given the choice between a TUI or a CLI program, I'd take the latter. You can always create your own interface from it. Better if it's backed by a library.

elevation 8mo ago

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

dwb 8mo ago
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.

fxtentacle 8mo ago

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

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

chrysoprace 8mo ago

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.

dwb 8mo ago
I’m definitely not advocating more little electron apps, and I’m totally with you on TUI’s benefits. I’m bemoaning the lack of imagination that has ended us up here and not in a situation where we can have, say, a small, low-footprint application that can deliver a more structured UI with minimal dependencies. It’s not an impossibility, it’s not even that difficult to imagine, we just don’t have the exact technology.
- flomo 8mo ago
  I'm with you. The thing is Windows 98 let you throw up a HTML window with almost zero overhead (the OS used the same libraries) and javascript could get data easily from another process via COM etc. Now like 25 years later, apparently our choices are shipping bespoke copies of Chrome and Node, OR making shit work on an emulated 1981 DEC terminal. Lack of vision is exactly right.
- exceptione 8mo ago
  We do. We are only stubborn. Cross platform and low-footprint: .net core => avalonia ui Java => JavaFX
- chrysoprace 8mo ago
  I think for the time being, there's no way to get around writing native UIs to get a native experience. Any sufficiently high level APIs will have to give up something. TUIs for me fill that niche because across any POSIX-compatible interface they will generally work the same, and modern high level languages make cross-compiling to terminals a breeze. Now to write a native UI across Windows, MacOS, Wayland and X11, that's a different story.
  - 8mo ago

worldsayshi 8mo ago

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?

coldtea 8mo ago

>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.

utilize1808 8mo ago
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".
- jazzyb 8mo ago
  > How many developers are using VSCode? How does that number compare with Emacs/Vim? Perhaps I'm in some sort of "TUI bubble", but I'd bet good money that Emacs/Vim users outnumber VSCode users by an order of magnitude. But maybe I'm just surrounded by *nix devs.
  - chrisweekly 8mo ago
    I'll take that bet
  - 9dev 8mo ago
    No need to guess, the SO survey is probably still representative of the state of development environments: https://survey.stackoverflow.co/2025/technology#1-dev-id-es https://survey.stackoverflow.co/2025/technology#1-dev-id-es Note that respondents may use multiple tools, but around 76% answered VSCode, whereas 24% answered Vim. So, I’d wager you’re indeed in a *nix bubble.

quotemstr 8mo ago

They are GUIs --- just minecraft GUIs. One day, we will rediscover why GUI toolkits exist. The only real advantage TUIs have over GUIs is easy remoting, TBH. Maybe that's enough for people. Otherwise? They're just hair shirts.

jxdxbx 8mo ago
I've use Claude to make myself a number of little tools and weird apps that only I would want lately. They need to be cross-platform between Linux and Mac and sometimes Windows. The best approaches I've found are Tauri (+Svelte for making layout easier) for lightweight GUIs but for anything more complex I prefer a TUI. The Ratatui framework works very well. A TUI feels like a "real" app as opposed to a glorified webpage. For actually serious software I'd want a native GUI on each platform.
- quotemstr 8mo ago
  > A TUI feels like a "real" app as opposed to a glorified webpage. Huh? "Feels"? Plenty of Electron/Tauri apps feel perfectly normal. Like I've been saying, the TUI craze is just a fad.
  - jxdxbx 8mo ago
    A TUI app feels like a native terminal app like I have used for my entire computing life, in DOS and then Linux. Electron apps feel like web apps no matter how good they are. I stopped using 1Password when it became an Electron app and became super janky. Discord, Slack, VS Code, the Signal desktop app, all suck UI-wise compared to actual native Mac apps, which even with Liquid Ass, are still better than using web technology for desktop apps. I know that lowest common denominator cross platform apps make economic sense to develop, whatever. They still suck to use.
    - quotemstr 8mo ago
      Again this word "feels". Is it not just nostalgia?

worthless-trash 8mo ago

> They flatten the structure of a UI under a character stream Isn't this ... everything though? Even the browser which you mention as better in the next paragraph.

dwb 8mo ago
No. The browser structures the page in both a DOM tree and an accessibility tree.
- worthless-trash 8mo ago
  What.. no, its text.. I've seen it in view source.. You're talking about yet another 'presented' data stream, which is different than the character stream. One can rebuild these at will, im sure.
  - dwb 8mo ago
    The source of a web page is parsed to form DOM and accessibility trees. The character stream of a TUI can’t be parsed into anything similar because it is not given in a formal language that can express those structures.
    - worthless-trash 8mo ago
      We're going to have to disagree, if you consider the 'browser page' as the interface, it falls into the same problem you see with TUI's... you must reach into the DOM and accessibility information not via the character stream but with an API, the TUI has the same issue. You've given me some great points to think about, thank you for the engaging conversation.

consp 8mo ago

> You’re forced to use it exactly the way it was designed and no different So ... Like all Apple products?

dwb 8mo ago
Not even close. Apple UIs - despite recent graphical howlers - have excellent accessibility APIs and are regularly praised by people that track such things. I’ve recently been building a macOS app and the UI testing is also based off it. There are apps that allow full keyboard navigation using it. I do agree that the window management side is much less customisable, though, and that does frustrate me.

simgt 8mo ago

What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore. I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.

dwb 8mo ago
I agree about the constraints. My ideal solution would also impose harsh constraints, but would also add just enough structure. I’m also frustrated by each app reinventing the same thing slightly differently.
fyredge 8mo ago
I don't quite agree with this. Feature discovery is much easier in GUI when most commonly used features are either in the first layer of menu or in standard hotkeys. In the worst case, you would do a search in GUIs that provide them. In CLI / TUI, no such function is present and you would basically have to man and scroll through all possible commands to find it, though I guess grep helps.
- 1718627440 8mo ago
  You accept search in GUI, but don't in man pages? Scrolling through actions in a tree-like menu structure is ok, but through a tree-like structure in the --help output is not? Feels inconsistent. The whole benefit of text-based interface is that search, filter and transformation is always available and completely independent of the running program. I can see the visual discoverability aspect for GUIs, but for the visual layout GUIs and TUIs are on par, the difference is rather in the rendering mechanism: pixel vs. character-based.
  - wredcoll 8mo ago
    >The whole benefit of text-based interface is that search, filter and transformation is always available That's the point about TUIs, they remove this benefit. You can't (practically) grep the output of btop or vim or whatever.

basilikum 8mo ago

I like that they are integrated into the terminal and stay in the terminal. For most things my terminal multiplexer is essentially my tiling window manager and everything that breaks out of that via its own window is very unergonomic and breaks the structured logic of my workflow. Technically just having a full GUI inside the boundaries of a terminal would be fine for a lot of things. But it's also one of these things where constraints make a lot of things better. Many GUIs are just really bloated and bad. TUIs just do not allow a lot of the sins of modern GUIs. I agree that they can get very clunky for non text based tasks or anything where you actually need custom text formating.

dwb 8mo ago
Yeah, I sympathise. This is another angle on the sorry state of affairs we find ourselves in.

JCattheATM 8mo ago

I don't think most GUIs expose any more structure than TUIs.