Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building Rich Terminal Dashboards

willmcgugan.com

Post reply on HN
Print view View original

71–80 of 123 posts

Re: Building Rich Terminal Dashboards

#71

Post by teddyh »

iib wrote: post #59
SiVal wrote: post #38

Earlier quoted context omitted.

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…

On Ubuntu, sometimes I like to do Ctrl-Alt-F3 to get into a tty, login, and then do `sudo init 3` to shutdown everything pertaining to the graphical shell. The interaction with the computer is much faster there. 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 need…

> sudo init 3` to shutdown everything pertaining to the graphical shell

The modern systemd equivalent is:

  systemctl isolate multi-user
> sudo init 7 […] which brings me back to my graphical shell.

  systemctl isolate graphical
or

  systemctl isolate default

Re: Building Rich Terminal Dashboards

#72

Post by willm »

sep_field wrote: post #70
willm wrote: post #67

Author of Rich here. Happy to answer any Rich related questions.

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.

Re: Building Rich Terminal Dashboards

#73

Post by Anthony-G »

iib wrote: post #59
SiVal wrote: post #38

Earlier quoted context omitted.

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…

On Ubuntu, sometimes I like to do Ctrl-Alt-F3 to get into a tty, login, and then do `sudo init 3` to shutdown everything pertaining to the graphical shell. The interaction with the computer is much faster there. 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 need…

I do something similar with a similar toolset – except that I use mutt for email, don’t use it for music and I’ve been experimenting with other browsers such as w3m and (e)links. I do this mostly for the distraction-free experience.

My workstation defaults to booting into the equivalent of run-level 3 (no display manager) and when I get tired of being in text mode, I just run `startx` for the graphical interface.

Re: Building Rich Terminal Dashboards

#74

Post by CJefferson »

naikrovek wrote: post #20
rexreed wrote: 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…

One thing, TUIs are MUCH MUCH worse for screen readers than (well made) websites.

TUIs (as currently designed) have no structure, so it's very difficult to move around from section to section. A website with headers and auto-wrapping text is much easier to move around and read with a screen reader.

Re: Building Rich Terminal Dashboards

#75

Post by [deleted] »

acemarke wrote: post #8
pugio wrote: post #5

Does anyone know of a similar library for node which does this? I've decided to make my next app TUI first, and then only add in a GUI much later, but I haven't seen anything that looks nearly as good as rich.

There's `blessed` [0], a plain JS lib similar to `ncurses`. There's also `react-blessed` [1], which is a React renderer that targets `blessed` as the display layer, and `ink` [2], which is also a text-based React renderer but using its own display layer. [0] https://github.com/chjj/blessed [1] https://github.com/Yomguithereal/react-blessed [2] https://github.com/vadimdemedes/ink

[deleted]

Re: Building Rich Terminal Dashboards

#76

Post by zokier »

naikrovek wrote: post #20
rexreed wrote: 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…

> No giant gaps between elements or wasted pixels. No fads which do silly things like hide scrollbars or other interactive elements

I call bullshit on this.

Using fixed character cell grid for UI absolutely wastes ton of space. First of all just basic text takes more space in fixed-width than variable width. But the biggest offender is any layout or ui elements that would not need whole cell. Even basic 1px horizontal line takes 10px of height or whatever. Places where 1 or 2 px padding could do will use full cell instead.

And then there is of course the space waste from forcing all text to be same size. For tons of applications the UI elements could do with smaller font than content, but none of that is possible with TUI.

I find your example of hiding scrollbars hilarious, considering that TUIs are in general far worse offenders in that area specifically. For example none of the examples for Rich here show scrollbars..

I do also believe that in terms of performance TUIs leave lot on the table, because they are forced to go through all sort of weird legacy layers. Pushing pixels on screen and receiving key events directly almost certainly should be faster/more efficient than going through tty layer and terminal emulation.

Re: Building Rich Terminal Dashboards

#77

Post by joseluis »

And 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

Re: Building Rich Terminal Dashboards

#78

Post by roel_v »

jeroenjanssens wrote: post #63
rexreed wrote: post #21

Earlier quoted context omitted.

Where's lynx when you need it? [0] [0] https://lynx.browser.org/ And I might add, it's the oldest web browser still being maintained. Since 1992.

Why does this website write "Un*x" as if it's some kind of swear word?

It was, at the time of the Unix wars, a rather childish way of 'protesting' the use of trademarks on the name 'UNIX' by AT&T, Novell, SCO etc. in their fights against other Unixy OS vendors. There were urban legends going around on IRC and Usenet that those companies would sue everybody using the word 'Unix' but not using the full name would absolve you of that responsibility. Legally this in the class of 'cops can't lie to you when you ask them if they're a cop' and 'free men doctrine' and such but it was wide spread at the time.

The irony is of course that Unix-like OS vendors spend so much time fighting each other that it was basically mutually assured destruction, and proprietary Unix systems went the way of the dinosaur after the dot com crash.

Re: Building Rich Terminal Dashboards

#79

Post by james-bcn »

rexreed wrote: 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 was thinking exactly the same thing! There used to be a really cool library for creating windows and buttons using ascii codes.
Post reply on HN