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

111–120 of 123 posts

Re: Building Rich Terminal Dashboards

#111

Post by naikrovek »

teddyh wrote: post #71
iib wrote: post #59

Earlier quoted context omitted.

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

Can anyone explain why systemd exists besides just saying "Leonart"?

The way people just replace things instead of addressing the issues in the old things bothers me.

init.d wasn't multithreaded. Ok, so give it threads. Etc.

Re: Building Rich Terminal Dashboards

#112

Post by CJefferson »

acapybara wrote: post #94
CJefferson wrote: post #74

Earlier quoted context omitted.

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.

At one point, web designers were making an effort to use semantic markup and create a "semantic web." That sure would have been nice for the screen readers.

In practice, much of the modern web still works well with screen readers (although it could be better of course). Some things break horribly (in particular, infinite scrolling is often a problem).

Re: Building Rich Terminal Dashboards

#114

Post by mixmastamyk »

How does this compare to Urwid, in terms of features, which I've used in the past to build such interfaces? For simpler stuff I often use my own console package, which everyone should write once, haha.

Architecturally however, I think terminal primitives and widgets should be separate layers/packages.

Re: Building Rich Terminal Dashboards

#115

Post by mixmastamyk »

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…

If you run fbterm on the console, you can get much improved unicode and color support.

Re: Building Rich Terminal Dashboards

#116

Post by rabidrat »

zokier wrote: post #76
naikrovek wrote: post #20

Earlier 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…

> 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 horizonta…

> 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.

This is not true; there is an underline attribute which can add a ~1px horizontal line without taking up any additional space.

Re: Building Rich Terminal Dashboards

#118

Post by naikrovek »

SiVal wrote: post #38
naikrovek wrote: post #20

Earlier 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…

I'm not opposed to TUIs managed in resizable windows on a graphical desktop. I just feel that most programs would be better suited to actual use if they were textual. Restraint fosters creativity and efficiency.

As an application developer, you'd certainly be much more in tune with how well your application is performing if you could feel a dip in performance the way I remember feeling it when a TUI wasn't responding quite as quickly as it was a few seconds earlier. Giving users insight into your application's performance is a good thing, because I think we put out and put up with unreasonably slow software far too often these days.

Re: Building Rich Terminal Dashboards

#119

Post by sidpatil »

rbanffy wrote: post #89
ho_schi wrote: post #86

Earlier quoted context omitted.

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.

I have the same one on my desk, for the same reason.

Re: Building Rich Terminal Dashboards

#120

Post by willm »

jawns wrote: post #101
willm wrote: post #67

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

Do you foresee any interplay behind a tool like Rich and terminal emulators like iTerm2, which provides some pretty sophisticated triggers based on terminal output? Or do you see them as two fundamentally different things with little overlap?

I probably wouldn't want to add features that weren't broadly compatible with all terminals. Unless they could be added in such a way that didn't break other terminals.

However, they could be implemented as an extension to Rich in another library.

Did you have something in mind?

Post reply on HN