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.
Building Rich Terminal Dashboards
51–60 of 123 posts
Re: Building Rich Terminal Dashboards
#52Another option for full-screen apps is Python Prompt Toolkit[1], which also handles keyboard and mouse input and can be used to implement editors[2].
Re: Building Rich Terminal Dashboards
#53The Console and Layout api looks really simple for creating dashboards. Another option for full-screen apps is Python Prompt Toolkit[1], which also handles keyboard and mouse input and can be used to implement editors[2]. [1] https://github.com/prompt-toolkit/python-prompt-toolkit [2] https://github.com/prompt-toolkit/pyvim
> prompt_toolkit 3.0 is completely type annotated and uses asyncio natively.
The rich source is also type annotated and very clean and readable.
Re: Building Rich Terminal Dashboards
#54Re: Building Rich Terminal Dashboards
#55Is it just me or does it seems like we're going backwards with things like this?
Re: Building Rich Terminal Dashboards
#56I dont need menus or dialogs, just something simple like top. Would this be the right library to use?
Re: Building Rich Terminal Dashboards
#57Earlier quoted context omitted.
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
#58The 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
Re: Building Rich Terminal Dashboards
#59Earlier quoted context omitted.
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…
I agree with your claims about the potential advantages of a TUI, but in this case, almost all of these TUIs using Rich will be running as GUI graphics inside a GUI window on top of a GUI OS subsystem, driven by an interpreted Python subsystem, all on an OS juggling many other simultaneous deep-stack processes. In other words, it's a keyboard-driven GUI app making use of the GUI advantages to provide you with your ch…
After I get bored, I do either `sudo init 7` to be sure, but mostly just Ctrl-Alt-F1, which brings me back to my graphical shell.
This method has the advantage that you are always on the same system, not needing anything else. Oh, also the music works, if you don't kill the GUI with the first `init` call.
Coupled with tmux, emacs/vim, nvlc, lynx, and coreutils, you can really be more productive there, from the extra speed, less memory requirements, and less available distractions.
EDIT: I could not find the actual link to the library either on HN or in the OP, so I am linking it here [1], for the convenience of myself and others.
Re: Building Rich Terminal Dashboards
#60Just 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…