Earlier quoted context omitted.
And everytime one toggles any setting that's is retained over htop restarts like tree view, the file gets edited. And you get diverging files everywhere. Annoyed me very much. Had to write a custom patch to disable some of it.
chmod +i .htoprc?
User power, not power users: htop and its design philosophy
31–40 of 98 posts
Re: User power, not power users: htop and its design philosophy
#32Earlier quoted context omitted.
Htop is not cli, and ncurses is in general just poor emulation of gui.
It's ok if you don't like TUIs, but don't call them "poor emulations" of GUIs. They do different things differently, but they achieve great results in their own ways. The mc file manager or ranger more than stands the comparison against graphical file managers.
In an ideal world the concept of TUI would not exist.
Re: User power, not power users: htop and its design philosophy
#33Earlier quoted context omitted.
> CLI is trending amongst dev's again Did it ever stopped being useful?
No, but it became a bit of a victim of being unfashionable. I think partly because of an influx of new devs who weren't in the position of having little choice but to learn at least some of the non-GUI way, particularly in the web sphere. As things have matured (arguably) and become more complex, and those devs have gained experience, they've started seeing the benefits of other methodologies. I just hope it doesn't…
Re: User power, not power users: htop and its design philosophy
#34Earlier quoted context omitted.
Keep a copy of .htoprc with your ssh keys. I have a skeleton /home on my keyring for using various machines with ease.
And everytime one toggles any setting that's is retained over htop restarts like tree view, the file gets edited. And you get diverging files everywhere. Annoyed me very much. Had to write a custom patch to disable some of it.
Re: User power, not power users: htop and its design philosophy
#35This is what quality software looks like: It has power features around the corner , which can be turned on by experts. But is nevertheless accessible by novices. CLI is trending amongst dev's again, and we should take a lesson by htop how to design a good user interface.
Htop is not cli, and ncurses is in general just poor emulation of gui.
Re: User power, not power users: htop and its design philosophy
#36Earlier quoted context omitted.
It's ok if you don't like TUIs, but don't call them "poor emulations" of GUIs. They do different things differently, but they achieve great results in their own ways. The mc file manager or ranger more than stands the comparison against graphical file managers.
Lets call them what they are: a workaround to display graphical content in a terminal windows. We need them because SSH, because we linux UI is a mess, because UI is hard, in embedded, etc. In an ideal world the concept of TUI would not exist.
A pathological example for me would be gvim. I tried using it for a while but I kept running into weird performance issues and general lagginess. Meanwhile from a terminal it Just Works. So I don't bother with it anymore, I always run Vim from a terminal and I never looked back.
In general I find that the terminal imposes two generally good constraints to application makers: everything must exist within a single window and mouse interaction is very limited (and not supported everywhere) so it's important that everything must be achievable with keyboard inputs.
These constraints disincentivize pathological mouse-driven "click click" pop up dialog fests which are the bane of my existence.
Re: User power, not power users: htop and its design philosophy
#37One of the first things I do when launching htop on a new box is to disable threads. The current way of showing threads by default is untenable because some programs launch hundreds of threads, making it hard to get an overview of a system unless you make the terminal size very large. I appreciate the author wanting users to discover a program running amok and producing a bunch of threads (anecdote: I've never seen i…
I feel like that's the crux of it. If I'm reading htop right I'm at ~140 tasks* and ~1000 threads.
The itch.io app that is hanging out in my system tray is currently sitting at ~200 threads by itself.
It's not helpful or educational to have pages of identically named threads especially when everything is only getting more multithreaded.
*and that's for my Cinnamon desktop, three firefox windows, thunderbird, steam, itch, a terminal and htop, lord knows if I was actually doing something with my computer.
Re: User power, not power users: htop and its design philosophy
#38> You have no idea how many times I was asked “hey, why are some processes green?” over these 15+ years — and no, it wasn’t annoying: each of these times it was an opportunity to teach someone about threads! That's because there isn't a easy way in htop to discover that. htop is great, I've used it for a decade, but I didn't know you could hide the threads (Shift+H) until I read this today. A "View options" / "Advanc…
Re: User power, not power users: htop and its design philosophy
#39> You have no idea how many times I was asked “hey, why are some processes green?” over these 15+ years — and no, it wasn’t annoying: each of these times it was an opportunity to teach someone about threads! That's because there isn't a easy way in htop to discover that. htop is great, I've used it for a decade, but I didn't know you could hide the threads (Shift+H) until I read this today. A "View options" / "Advanc…
Re: User power, not power users: htop and its design philosophy
#40Earlier quoted context omitted.
Lets call them what they are: a workaround to display graphical content in a terminal windows. We need them because SSH, because we linux UI is a mess, because UI is hard, in embedded, etc. In an ideal world the concept of TUI would not exist.
Sometimes less is more. Having access to more features sometimes leads devs to bloat their applications and make them subjectively less usable. A pathological example for me would be gvim. I tried using it for a while but I kept running into weird performance issues and general lagginess. Meanwhile from a terminal it Just Works. So I don't bother with it anymore, I always run Vim from a terminal and I never looked ba…