I second that, even better would be if every type chart would be a folder, with a readme containing a screenshot and the code example. That would be top notch.
Not every one, but if it looks like something I might use, I do take a quick look at it and any upstream it came from. It keeps me from using something when I shouldn't and have to rip it out later.
This project has made me think about more about the difference between TUI's and "command-line" (CLI) apps as categories. Traditionally CLIs were kind of run-and-exit tools, and "real" TUIs were long-running, stateful apps, but what we're creating seems to sit somewhere in between the to.
With richer terminals and libraries like this, the distinction feels more about interaction style than environment. Curious how others think about that boundary when designing tools that work in terminals.
I will definitely give it a try. Terminal UI‘s are super interesting in my opinion, because I feel like they can improve productivity. Hopefully this library can be compiled into a single binary that exposes an application icon. That’s one of the biggest hurdles I experienced with „GUI only“ users - they want something to double click on to start.
The Readme for a UI library benefits enormously from screenshots, even terminal based UIs.
I second that, even better would be if every type chart would be a folder, with a readme containing a screenshot and the code example. That would be top notch.
PS: looks great on the surface!
Next updates will include better docs and many screenshots/examples, thanks!
If you don’t already have a preferred workflow for autogenerating these, you might be interested in vhs https://github.com/charmbracelet/vhs
I am not affiliated, I just think it’s a neat tool
Screenshots added for all widgets :) Flex layouts were added too!
As a FYI, you removed the original author's name from your license information. Per the MIT license, you need to preserve their copyright in your fork
Genuinely curious. Do you actually open the license file on all repos posted to HN?
Not every one, but if it looks like something I might use, I do take a quick look at it and any upstream it came from. It keeps me from using something when I shouldn't and have to rip it out later.
Will fix, thanks
This project has made me think about more about the difference between TUI's and "command-line" (CLI) apps as categories. Traditionally CLIs were kind of run-and-exit tools, and "real" TUIs were long-running, stateful apps, but what we're creating seems to sit somewhere in between the to.
With richer terminals and libraries like this, the distinction feels more about interaction style than environment. Curious how others think about that boundary when designing tools that work in terminals.
I will definitely give it a try. Terminal UI‘s are super interesting in my opinion, because I feel like they can improve productivity. Hopefully this library can be compiled into a single binary that exposes an application icon. That’s one of the biggest hurdles I experienced with „GUI only“ users - they want something to double click on to start.
Think tabs widget would look better if it was more like a text area in appearance. Tab title should be connected to its content.
Agreed, tabs widget needs work, I will try to get into the next release! Thanks!
It is interesting that suddenly the Terminal UI became popular. I am super happy to see this kind of thing pop up.