Live data from Hacker News

Building Rich Terminal Dashboards

willmcgugan.com

41–50 of 123 posts

Re: Building Rich Terminal Dashboards

#41

Earlier quoted context omitted.

Except you can bake apps into a single stand-alone binary executable for both Node.JS[1] and Python[2] [1] https://www.npmjs.com/package/pkg [2] https://github.com/marcelotduarte/cx_Freeze

Can’t you just shebang a python script to make it feel like a normal executable?

If you zip a Python package with a __main__.py, it’s executable by the interpreter.

Re: Building Rich Terminal Dashboards

#42
post #17

The 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

I miss the simplicity and utility of textual UIs. Nothing unneeded, and everything you need. No filler. No giant gaps between elements or wasted pixels. No fads which do silly things like hide scrollbars or other interactive elements. Except for CAD applications and some games, almost everything we do online today could be accomplished via textual UI. Almost the entire internet could be replaced with TUIs and a lot o…

> They're probably a lot easier for screen-readers, too.

That might be true for more minimal TUIs, but I don't think most screen-readers can handle the multi-paneled ones like OP.

Re: Building Rich Terminal Dashboards

#43
post #17

The 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

I wouldn't say it repeats it. These new programs are similar to the old ones in much the same way that new books are similar to old books. The medium is the same but what's being expressed and accomplished is vastly different. Two specific categories that come to mind: these new programs are vastly easier to use with modern UI principles than "RTFM" you'd find in the old ones; and validation/error handling is similar…

What tools are the car tire in this analogy? I recall it was ridiculously easy to develop rich text applications from Turbo Pascal/Turbo Vision. I believe there’s a modern port of Turbo Vision as well

Re: Building Rich Terminal Dashboards

#45
This 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?

Re: Building Rich Terminal Dashboards

#46

This 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?

Craigslist approves: https://sfbay.craigslist.org/

Re: Building Rich Terminal Dashboards

#47
post #9

Is this better than splitting panes up with Tmux or similar? You end up losing the ability to pipe things. What do you gain?

You could detect if stdout is a terminal and then decide for fanciness or machine readability. I think this, along with flags for manually setting rich features, would provide the best of both worlds.

Re: Building Rich Terminal Dashboards

#48

For C++ers, there’s ImTui https://github.com/ggerganov/imtui an ncurses backend for ImGui https://github.com/ocornut/imgui

wtfutil is a another terminal dashboard [0]. It uses .yml configuration files to define the layout and the content of the splits.

At some point, I used ImTui to create a more convenient way to create these .yml configuration files: wtf-tui [1]. I also made an emscripten port of wtf-tui for easy testing in the browser [2]

[0] - https://wtfutil.com

[1] - https://github.com/ggerganov/wtf-tui#wtf-tui

[2] - https://wtf-tui.ggerganov.com

Re: Building Rich Terminal Dashboards

#49
post #36

Just realized that the post author submitted[0] it hours before I did, but it didn't come up in search because it was dead at the time. This is sad because Will writes great posts[1] and great software[2], but somehow his submissions mentioning Rich tend to end up dead. Would it be a case of bad project name for HN titles? [0] https://news.ycombinator.com/item?id=26147831 [1] https://www.willmcgugan.com/blog/tech/ [2…

@dang perhaps worth merging into the original author's post to give them credit?
Post reply on HN