A year of building for the terminal
textual.textualize.io
A year of building for the terminal
1–10 of 95 posts
Re: A year of building for the terminal
#2Wow, I used to like midnight commander a lot but moved away from it. Seeing things like that being built relatively easily makes me want to try using this for my personal project! Good work.
Re: A year of building for the terminal
#3cool! something like this for golang?
Re: A year of building for the terminal
#4cool! something like this for golang?
Check out the Charm libs by https://charm.sh/
Re: A year of building for the terminal
#5[dead]
Re: A year of building for the terminal
#6This is an interesting framework, it's refreshing in that you don't need to bootstrap a whole web browser (electron) to build a user interface.
I don't really see it's use case though, mostly cli is used for either:
A) Ability to run in automated environments (e.g CI) - think aws cli
B) Interop, think piping data from grep to xargs
C) Hacking - writing a script quick and dirty to just get a job done
I'd have thought if I was investing enough time to think about user interface, I'd just build my tool in Qt/GTK/JavaFX/Electron etc
Though I can see the argument that if I was building an app with keybinds as controls rather than mouse primarly, probably a framework like this would be the way to go.
Re: A year of building for the terminal
#7Has TUI accessibility improved at all?
Textualize (Python), Charm (Go) and tui-rs/Cursive (Rust) make building TUI apps appealing, but I'm put off by the idea of making apps like this if they have no screenreader support.
Re: A year of building for the terminal
#8The terminal still has and always will have great potential as the glue that holds all computing together. Users refine their skill in a few, interoperable and flexible standard tools, and any command that turns out to be useful can immediately be part of a script that automates and simplifies this task forever.
It all hinges not necessarily on more fanciness in the terminal, but on the availability of data to work on, on other systems to open their data to the terminal in some way. Many SAAS tools have no interest or incentive to do that; is the trend going away from data available the terminal? Example, Kibana and Splunk are silos that provide powerful ways to analyze logs - what else could you possible want more?
Well, even the most sophisticated logfile queries can be repetitive, and those advanced search patterns could be distilled into a script that follows the user's hunches, add a bit of an ad-hoc regression test, correlate it with data from elsewhere, take user input from log files and use it in automated tests, maybe feed it all into a terminal based statistical analysis tool? I don't see myself doing any of that, the devs want a clickable link to the relevant Kibana and they are getting that.
More colors in terminals are nice but is it enough to make a difference?
Re: A year of building for the terminal
#9Has TUI accessibility improved at all? Textualize (Python), Charm (Go) and tui-rs/Cursive (Rust) make building TUI apps appealing, but I'm put off by the idea of making apps like this if they have no screenreader support.
I think we will need new standards here, because terminal emulators currently don't have any semantic information about what TUI programs are rendering. Browsers have the benefit of HTML to know this is a button, and that is a paragraph. A terminal is an unstructured grid of characters. The best we can hope for is for terminal emulators to use heuristics or AI to make sense of what TUI programs are rendering.
Re: A year of building for the terminal
#10This is an interesting framework, it's refreshing in that you don't need to bootstrap a whole web browser (electron) to build a user interface. I don't really see it's use case though, mostly cli is used for either: A) Ability to run in automated environments (e.g CI) - think aws cli B) Interop, think piping data from grep to xargs C) Hacking - writing a script quick and dirty to just get a job done I'd have thought…
The uses for the terminal outlined are pretty limited. These are kind of the use cases I would expect from an average use that runs scripts or does occasional scripting work. It doesn’t really take into account more advanced users who do practically live in the terminal and do all the things outlined in the article (use a file browser from within a terminal)
The target users here are pretty clearly them. It’s pretty hard to make usable tuis because the libraries kinda suck or are ancient - this project seems to be looking to change that.
I’d even argue that the reason more people don’t use TUIs as much as GUIs is because TUIs aren’t always as intuitive or user friendly. Hopefully this helps that and makes them easier to build usable intuitive guis