It’s hard not to love whatever the Charm team puts out!
Haven’t had a chance to have more than a glance at this, but would a TUI such as this support pipes in the traditional Unix sense, where if I pipe into this program it can automatically fill any of the fields? I would still love to a have way to run something like this both interactively and automatically.
Thank you so much! We really appreciate the kind words ❤️
Yes supporting pipes is something the developer building the form can definitely do, they can pre-populate the values based on stdin or command line flags and if all values are provided then simply skip the interactivity.
The differentiation between a TUI and a GUI doesn’t hinge on whether it operates within a terminal, but rather, its design centered on interactivity. This can be exemplified through the use of modes, keybindings, panes, and so forth, with lazygit serving as a prime example. In my opinion, this project leans more towards the GUI side.
That’s an interesting way of thinking about it. I always assumed that TUIs were any text-based user interface as the name suggests, regardless of the interactivity. For example, vim / neovim are TUIs even though they are much more complex than simple GUI applications (for example minesweeper).
I always assumed that TUIs were any text-based user interface as the name suggests, regardless of the interactivity
Yes. Text-based. Line characters and VT220 escape sequences are not text though, any more than a base64-encoded png is text. Text can be composed and manipulated with lots of different tools (not just humans), so interactivity and composability really are the main things you will have with a Text-based user interface.
https://en.wikipedia.org/wiki/Impulse_Tracker runs in what is called “text mode”, and I don’t think it’s a TUI. I don’t think line art and box-drawing characters are “text” just because they’re conveniently-located and sized in a font-block and there’s special circuitry to translating a buffer of characters and attributes into pixels instead of working with pixels directly. You can’t run this in a terminal, you can’t pipe it to anything, and keyboard input is controlled by each control individually (like every GUI you have ever used). Minesweeper is a GUI even when it runs in a terminal for exactly the same reason: https://minesweeper.mia1024.io
http://acme.cat-v.org on the other hand, only ever works with a raster display (graphical pixels), and yet I think it’s undeniably a TUI because there is literally no other metaphor the user is exposed to except in terms of text. There are no widgets, and every control and button always works the same way, and you most certainly can pipe other programs into and out of acme (it’s way more powerful can :!/% on vi)
I usually refer to emacs and vim as a gui, especially when talking about pull-down menus, tool-bar clickable buttons and the protected forms interfaces used in configuration or in some vimscripts, but ex (the editor that vi is built on) is absolutely a TUI, and the level of composition that is possible in emacs and vi is high enough that they can be used-reasonably as TUI, so I don’t think it’s worth quibbling too much, but surely Microsoft Notepad.exe is a GUI, and so if composition isn’t as important as I think, maybe vim/neovim are GUI as well.
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
Ok, I might have not gotten your point first time reading it. So, it’s more about what (text, both ‘plain’ and commands) you interact with, than how (acme via mouse interactions)?
Would it be fair to call Excel a TUI, by the same reasoning? I mean editing text in cells, writing formulas and such, not the graphing things. Maybe pre-ribbon versions of it.
I think it depends exactly on what you’re talking about: visicalc and (better) sc are both TUI spreadsheets, and I would agree that “editing text in cells, writing formulas and such” is a big part of it, so maybe it’s possible to talk about the TUI-ness of Excel, or the TUI that’s inside Excel. Some ancient MS-DOS version of Excel might’ve been a TUI.
But every piece marketing collateral I’ve ever seen about Excel shows front-and-center that graphing, a rich set of programmable interface controls and widgets, so I think it would be otherwise very strange for someone to refer to it as a TUI.
Incredibly slick! Makes me wish I used Go. I did notice that gum exists, which I’ll definitely try out. Not quite as cool as huh/bubbletea, obviously, but still cool. Thanks!
Back in the DOS days, I remember building some very complicated atrocities using wbat, which let you lay out dialogue boxes using ASCII art at the bottom of your batch files.
huh? has a special rendering option designed specifically for screen readers. You can enable it with form.WithAccessible(true).
Glad to see accessibility as more than an afterthought.
I’ve been wondering though, what’s preventing a TUI program from talking directly on the accessibility bus, and offering a UI to AT users that’s decoupled from the TUI presentation?
I started exploring that at work, but didn’t get to the point where I find out why it’s a bad idea yet.
It’s hard not to love whatever the Charm team puts out!
Haven’t had a chance to have more than a glance at this, but would a TUI such as this support pipes in the traditional Unix sense, where if I pipe into this program it can automatically fill any of the fields? I would still love to a have way to run something like this both interactively and automatically.
Thank you so much! We really appreciate the kind words ❤️
Yes supporting pipes is something the developer building the form can definitely do, they can pre-populate the values based on
stdinor command line flags and if all values are provided then simply skip the interactivity.The differentiation between a TUI and a GUI doesn’t hinge on whether it operates within a terminal, but rather, its design centered on interactivity. This can be exemplified through the use of modes, keybindings, panes, and so forth, with lazygit serving as a prime example. In my opinion, this project leans more towards the GUI side.
That’s an interesting way of thinking about it. I always assumed that TUIs were any text-based user interface as the name suggests, regardless of the interactivity. For example, vim / neovim are TUIs even though they are much more complex than simple GUI applications (for example minesweeper).
Yes. Text-based. Line characters and VT220 escape sequences are not text though, any more than a base64-encoded png is text. Text can be composed and manipulated with lots of different tools (not just humans), so interactivity and composability really are the main things you will have with a Text-based user interface.
https://en.wikipedia.org/wiki/Impulse_Tracker runs in what is called “text mode”, and I don’t think it’s a TUI. I don’t think line art and box-drawing characters are “text” just because they’re conveniently-located and sized in a font-block and there’s special circuitry to translating a buffer of characters and attributes into pixels instead of working with pixels directly. You can’t run this in a terminal, you can’t pipe it to anything, and keyboard input is controlled by each control individually (like every GUI you have ever used). Minesweeper is a GUI even when it runs in a terminal for exactly the same reason: https://minesweeper.mia1024.io
http://acme.cat-v.org on the other hand, only ever works with a raster display (graphical pixels), and yet I think it’s undeniably a TUI because there is literally no other metaphor the user is exposed to except in terms of text. There are no widgets, and every control and button always works the same way, and you most certainly can pipe other programs into and out of acme (it’s way more powerful can :!/% on vi)
I usually refer to emacs and vim as a gui, especially when talking about pull-down menus, tool-bar clickable buttons and the protected forms interfaces used in configuration or in some vimscripts, but ex (the editor that vi is built on) is absolutely a TUI, and the level of composition that is possible in emacs and vi is high enough that they can be used-reasonably as TUI, so I don’t think it’s worth quibbling too much, but surely Microsoft Notepad.exe is a GUI, and so if composition isn’t as important as I think, maybe vim/neovim are GUI as well.
There are lots of examples on wikipedia that includes interactive elements and terminals’ features: https://en.wikipedia.org/wiki/Text-based_user_interface
What is your definition based on?
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
I just explained that.
Ok, I might have not gotten your point first time reading it. So, it’s more about what (text, both ‘plain’ and commands) you interact with, than how (acme via mouse interactions)?
Would it be fair to call Excel a TUI, by the same reasoning? I mean editing text in cells, writing formulas and such, not the graphing things. Maybe pre-ribbon versions of it.
I think it depends exactly on what you’re talking about: visicalc and (better) sc are both TUI spreadsheets, and I would agree that “editing text in cells, writing formulas and such” is a big part of it, so maybe it’s possible to talk about the TUI-ness of Excel, or the TUI that’s inside Excel. Some ancient MS-DOS version of Excel might’ve been a TUI.
But every piece marketing collateral I’ve ever seen about Excel shows front-and-center that graphing, a rich set of programmable interface controls and widgets, so I think it would be otherwise very strange for someone to refer to it as a TUI.
In my opinion the Oberon System is also a TUI, even though it is graphical. It definitely follows similar interactivity patterns as TUIs.
Incredibly slick! Makes me wish I used Go. I did notice that gum exists, which I’ll definitely try out. Not quite as cool as huh/bubbletea, obviously, but still cool. Thanks!
Thanks so much for the kind words ❤️
For a moment I thought this might be an interactive form editor for TUI apps, which would be interesting. Has one ever been made?
This is very nice, though.
VB 1.0 for DOS, perhaps?
Back in the DOS days, I remember building some very complicated atrocities using
wbat, which let you lay out dialogue boxes using ASCII art at the bottom of your batch files.ASCIIFlow + ChatGPT can get you pretty close…
https://blog.orhun.dev/ratatui-0-22-0/
Seems timely since https://github.com/AlecAivazis/survey was archived in Sept of this year.
Oh interesting, I’d not seen that, thanks!
Glad to see accessibility as more than an afterthought.
I’ve been wondering though, what’s preventing a TUI program from talking directly on the accessibility bus, and offering a UI to AT users that’s decoupled from the TUI presentation?
I started exploring that at work, but didn’t get to the point where I find out why it’s a bad idea yet.
Random, but I really like the color schema
Thanks so much!