I don't want my terminal tools rely on a Python pip library. This Rich really looks cool and is nice, but nothing for (my) server use.
(Thanks to @joseluis who posted about notcurses here)
Building Rich Terminal Dashboards
81–90 of 123 posts
Re: Building Rich Terminal Dashboards
#82[Sorry for the spam] If you want to create charts quickly there's also: https://github.com/FedericoCeratto/dashing
Looks great, thanks for the link! Some very nice examples of other cool stuff that depends on the blessed Python package: https://github.com/jquast/blessed
Re: Building Rich Terminal Dashboards
#83Reminds me of Window, which has keyboard input:
https://github.com/lukeb42/window
https://github.com/lukeb42/emissary
Re: Building Rich Terminal Dashboards
#84This is really interesting! I've been thinking of creating a TUI version of a marketplace I'm running in the UK. The idea is that most of our time on marketplaces is spent on discovering the product we are looking for and that is much easier to do without all the bloat of modern apps. What do the people on HN think?
Great idea. I've been toying around with Ink, which is a TUI renderer for React. My idea is to port our existing React front end to it and offer an installable "native" TUI front-end option for our service.
Re: Building Rich Terminal Dashboards
#85The future repeats the past. This looks much like the back-end systems I used to design on TurboPascal in the late 1980s / early 1990s. https://ilyabirman.net/meanwhile/pictures/tp-80.png
Well, you’re in luck! There’s a modern version of TurboVision that works on modern systems. I used it the other day to show tvedit to some of the folks at work who were using nano. They were kinda mind-blown by the fact that editors in the late 80’s/early 90’s weren’t terrible.
Re: Building Rich Terminal Dashboards
#86And there's also Notcurses[0][1], which facilitates the creation of modern TUI programs, making full use of Unicode and 24-bit TrueColor. It presents an API similar to that of Curses, riding atop Terminfo. It's made in C, with C++, Python & Rust wrappers. [0] https://notcurses.com/ [1] https://github.com/dankamongmen/notcurses
Interesting how the show their work results in a completely differnt way. I'm looking at it, because the C, C++ and the Rust interface are my working area.
I love TUIs and think they are used to less. Easy usage, concise overview and high efficiency. TUIs seem to naturally restrict itself, keep tight to the task and therefore work better. Mileage may vary well ;)
Re: Building Rich Terminal Dashboards
#87Check out React Ink, it's pretty slow and probably not as polished/feature packed, but it does the job.
That being said, working in the CLI with a GUI does not work very well.
Having the option to search for strings logged in some pages ago is really handy.
Re: Building Rich Terminal Dashboards
#88And there's also Notcurses[0][1], which facilitates the creation of modern TUI programs, making full use of Unicode and 24-bit TrueColor. It presents an API similar to that of Curses, riding atop Terminfo. It's made in C, with C++, Python & Rust wrappers. [0] https://notcurses.com/ [1] https://github.com/dankamongmen/notcurses
Using curses also allows it to work on terminals that are not ANSI terminals (even though most of the actual hardware that still survives understand most of the VT-100 sequences).
Also, not all terminals have uniform coverage for ANSI codes. Apple's Terminal.App does a good job with double-width and double-height, but lacks the SGR 53 overline that VTE, Konsole and Microsoft Windows Terminal have (and that makes status lines so much better).
Re: Building Rich Terminal Dashboards
#89And there's also Notcurses[0][1], which facilitates the creation of modern TUI programs, making full use of Unicode and 24-bit TrueColor. It presents an API similar to that of Curses, riding atop Terminfo. It's made in C, with C++, Python & Rust wrappers. [0] https://notcurses.com/ [1] https://github.com/dankamongmen/notcurses
Interesting how the show their work results in a completely differnt way. I'm looking at it, because the C, C++ and the Rust interface are my working area. I love TUIs and think they are used to less. Easy usage, concise overview and high efficiency. TUIs seem to naturally restrict itself, keep tight to the task and therefore work better. Mileage may vary well ;)
Restraint is a great tool for engineers. When you can't to everything, you focus on what matters the most.
I used to have an IBM 3151 terminal on my desk (I wish I could afford a 3278/9 or 3290) connected over 9600 bps to my workstation. It's a great to remind me to keep things simple.
Re: Building Rich Terminal Dashboards
#90Earlier quoted context omitted.
This is awesome! Do you have plans/a timeline for keyboard/mouse input?
Plans, yes. Still thinking about the best way to do it without inventing too many wheels. Timeline depends on inspiration and free time. Although lately with the pandemic free time hasn't been a problem.
I commented on this in another HN discussion thread [1] on Blessed [2]. You might want to look at what Vermont Views did [3] to avoid reinventing the wheel of what to implement. I'm sure if you put the call out for it, someone, somewhere, reading on HN, will be able to post up the documentation if you want a detailed look, or send you the obfuscated source code (which these days could probably be re-constituted with modern re-factoring editors). I tried emailing and hard copy mail contacting them a few years back to buy the rights so I could turn around to open source it as I anticipated a resurgence of interest in TUI's because the browser-based latency issue is simply not improving fast enough, but never got a response, so as far as I can tell, they went abandonware (their corporate form is inactive [4], but someone is updating their office address as recently as a couple years ago, so I might give a shot at contacting them again).
[1] https://news.ycombinator.com/item?id=14405186
[2] https://github.com/chjj/blessed
[3] http://web.archive.org/web/20091011010412/http://www.vtsoft....