7 ms·

I'm constantly annoyed by programs that try to make "fancy" terminal UIs, with a ton of formatting, colors, utilizing as many terminal features as they possibly

I'm constantly annoyed by programs that try to make "fancy" terminal UIs, with a ton of formatting, colors, utilizing as many terminal features as they possibly can. It just seems like such a hack to me. The terminal IS NOT meant for fancy user interfaces, stop abusing it for that. Use a real GUI framework that has actual graphics instead of character cells. The question is where to draw the line, I believe things like htop, tmux etc are reasonable, so it's hard to say whether a particular program is "abusing" the terminal.

ykonstant 3y ago
I have the opposite sentiment; I grew up with DOS TUI and miss them dearly. Not all of them were great, but when the programmers focused on the UI experience, you got some really nice results. I do come from a "command line" culture, rather than a "terminal" culture, though; in particular, I don't understand why the command line is "not meant for fancy user interfaces". A "terminal" in the sense of the 60s might, but I don't care about that. I care about the system I have.
- qweqwe14 3y ago
  > I don't understand why the command line is "not meant for fancy user interfaces" "command line" is a different term from a "terminal", but the reason why it's not great for graphical UIs is that character cells are a bad abstraction for it, people just keep adding more and more features/extensions to terminals to compensate for it, which isn't a good direction at all
  - vidarh 3y ago
    Plenty of fancy user interfaces do not need to be graphical, but can still benefit from better textual presentation. As for "features", there are very few features in modern terminals that affect display that weren't either present in "actual" terminal hardware several decades ago or are spiritual successors to that. E.g. displaying images in terminals has been a thing since at least 1981, yet a whole lot of terminals haven't supported it until it started getting a bit of a resurgence lately. I don't agree it's not a good direction - GUI's are way too complex for a whole lot of applications, where terminals allow you to output quite advanced things with a handful of lines of code and no external dependencies. If there was a push to make GUI protocols simpler (instead of far more work, as with Wayland) for trivial programs to output, I might be more open to this view.
vidarh 3y ago
And I'm annoyed by programs that don't make full use of it, to the point where I e.g. use "grc" [1] to colorize the output of a lot of commands. I don't want to use "a real GUI framework" for it, because that is 1) way more complexity, 2) not network transparent enough (yes, I can use X; no it's not pleasant over a network with any kind of latency), 3) I often don't want "actual graphics" - I want something constrained to a grid and that I can cut and paste as text, 4) "a real GUI framework" would prevent me from further filtering and rewriting the output, the way I do with grc. [1] https://github.com/garabik/grc https://github.com/garabik/grc
CaptainFever 3y ago
I think the main issue is with SSH. Remote console access is a lot faster and less resource intensive for servers than remote desktop, so htop and tmux really help for servers and sysadmins. Otherwise yes, generally I think TUIs should be GUIs instead.
- minetest2048 3y ago
  And embedded developers too, we still use UARTs and TUIs just work
jackpeterfletch 3y ago
They're trying to leverage the advantages the terminal brings: - Portable API. - A directory context, stack based workflow, in which unrelated programs are be executed together. While working through the major disadvantages 'traditional' terminal apps have: - Lack of visual hints, memory prompts, discoverability in the UI design. Those disadvantages aren't a problem for everyone, have stood in awe of many a terminal wizard as they fly through tasks that would take me much longer, terminal or not - and if that's you, you have my envy. But for me, my brain just isn't wired to be able to quickly recall all the flags, shortcuts, workflows, and other nuances of 30+ terminal apps, of varying usage frequency. That's why I like k9s as alternative to kubectl, it guides me, reminds me. Could 'k9s' be a native GUI? Of course, but it probably wouldn't exist if it had to be. So I hope there's room for both!
massysett 3y ago
Htop uses a huge number of terminal features. It uses color, vertical bars to make graphs, and you can move a cursor to select processes. So if htop is reasonable, what is an example of something not reasonable?
- vidarh 3y ago
  htop is indeed one of the test cases I use to see if my terminal is rendering things right because of how many terminal features it uses.
graemep 3y ago
I like some fancy terminal UIs (e.g. lazygit), but what I like most about them is the keyboard navigation which could be replicated in a GUI, but is often not. They also have some advantages - like painlessly working across a network with low lag.
steventhedev 3y ago
There are a few key things that you get by targeting a terminal for your UI: * Remote desktop forwarding through tmux, ssh, mosh, etc * Instrumentation of your UI - simply replay the input * Screen recording with asciinema Not to mention that you can target the exact same UI framework across Linux, Mac, Windows, and more. On the other hand, it doesn't play well with your desktop environment. Taken to an extreme - if all your daily drivers are in the terminal: * You can't easily tell them apart because they all have the same icon * Some of those bells and whistles might not be supported in all emulators - tmux and mosh are probably a good baseline. * Accessibility support is lacking (TFA). This is probably more of a demand side problem than anything else though. On the whole, it's a decent enough UI target for an inner platform on the level with the web - all we need now is Muon - a wrapper that includes a terminal emulator so you can write "native" terminal programs with their own icons.
blipmusic 3y ago
What? No. I can run these on a server and get the same UI as locally, which is great. As with everything else sometimes TUIs make sense, sometimes not. There are a lot of crappy GUIs out there as well, which would have been better served as CLI tools (in my subjective opinion). And what is "IS NOT meant for fancy user interfaces" supposed to mean? (and what about various constraints back in the day as the actual reason for a data in/data out-only interface as opposed to "intent"?) I could argue that tmux is "fancy", since it is a multi-panel workspace, mirroring GUI capabilities, but apparently that's Ok according to you. So your conclusion seems to be that TUIs are actually ok in general - you just don't like bad/over designed interfaces (subjective terms, of course), which is understandable. Sorry, but I don't get your point. Bad interfaces are everywhere. (I kind of like fancy TUIs when they make sense, to be honest, so there's that)

ykonstant 3y ago

I have the opposite sentiment; I grew up with DOS TUI and miss them dearly. Not all of them were great, but when the programmers focused on the UI experience, you got some really nice results. I do come from a "command line" culture, rather than a "terminal" culture, though; in particular, I don't understand why the command line is "not meant for fancy user interfaces". A "terminal" in the sense of the 60s might, but I don't care about that. I care about the system I have.

qweqwe14 3y ago
> I don't understand why the command line is "not meant for fancy user interfaces" "command line" is a different term from a "terminal", but the reason why it's not great for graphical UIs is that character cells are a bad abstraction for it, people just keep adding more and more features/extensions to terminals to compensate for it, which isn't a good direction at all
- vidarh 3y ago
  Plenty of fancy user interfaces do not need to be graphical, but can still benefit from better textual presentation. As for "features", there are very few features in modern terminals that affect display that weren't either present in "actual" terminal hardware several decades ago or are spiritual successors to that. E.g. displaying images in terminals has been a thing since at least 1981, yet a whole lot of terminals haven't supported it until it started getting a bit of a resurgence lately. I don't agree it's not a good direction - GUI's are way too complex for a whole lot of applications, where terminals allow you to output quite advanced things with a handful of lines of code and no external dependencies. If there was a push to make GUI protocols simpler (instead of far more work, as with Wayland) for trivial programs to output, I might be more open to this view.

vidarh 3y ago

And I'm annoyed by programs that don't make full use of it, to the point where I e.g. use "grc" [1] to colorize the output of a lot of commands. I don't want to use "a real GUI framework" for it, because that is 1) way more complexity, 2) not network transparent enough (yes, I can use X; no it's not pleasant over a network with any kind of latency), 3) I often don't want "actual graphics" - I want something constrained to a grid and that I can cut and paste as text, 4) "a real GUI framework" would prevent me from further filtering and rewriting the output, the way I do with grc. [1] https://github.com/garabik/grc https://github.com/garabik/grc

CaptainFever 3y ago

I think the main issue is with SSH. Remote console access is a lot faster and less resource intensive for servers than remote desktop, so htop and tmux really help for servers and sysadmins. Otherwise yes, generally I think TUIs should be GUIs instead.

minetest2048 3y ago
And embedded developers too, we still use UARTs and TUIs just work

jackpeterfletch 3y ago

They're trying to leverage the advantages the terminal brings: - Portable API. - A directory context, stack based workflow, in which unrelated programs are be executed together. While working through the major disadvantages 'traditional' terminal apps have: - Lack of visual hints, memory prompts, discoverability in the UI design. Those disadvantages aren't a problem for everyone, have stood in awe of many a terminal wizard as they fly through tasks that would take me much longer, terminal or not - and if that's you, you have my envy. But for me, my brain just isn't wired to be able to quickly recall all the flags, shortcuts, workflows, and other nuances of 30+ terminal apps, of varying usage frequency. That's why I like k9s as alternative to kubectl, it guides me, reminds me. Could 'k9s' be a native GUI? Of course, but it probably wouldn't exist if it had to be. So I hope there's room for both!

massysett 3y ago

Htop uses a huge number of terminal features. It uses color, vertical bars to make graphs, and you can move a cursor to select processes. So if htop is reasonable, what is an example of something not reasonable?

vidarh 3y ago
htop is indeed one of the test cases I use to see if my terminal is rendering things right because of how many terminal features it uses.

graemep 3y ago

I like some fancy terminal UIs (e.g. lazygit), but what I like most about them is the keyboard navigation which could be replicated in a GUI, but is often not. They also have some advantages - like painlessly working across a network with low lag.

steventhedev 3y ago

There are a few key things that you get by targeting a terminal for your UI: * Remote desktop forwarding through tmux, ssh, mosh, etc * Instrumentation of your UI - simply replay the input * Screen recording with asciinema Not to mention that you can target the exact same UI framework across Linux, Mac, Windows, and more. On the other hand, it doesn't play well with your desktop environment. Taken to an extreme - if all your daily drivers are in the terminal: * You can't easily tell them apart because they all have the same icon * Some of those bells and whistles might not be supported in all emulators - tmux and mosh are probably a good baseline. * Accessibility support is lacking (TFA). This is probably more of a demand side problem than anything else though. On the whole, it's a decent enough UI target for an inner platform on the level with the web - all we need now is Muon - a wrapper that includes a terminal emulator so you can write "native" terminal programs with their own icons.

blipmusic 3y ago

What? No. I can run these on a server and get the same UI as locally, which is great. As with everything else sometimes TUIs make sense, sometimes not. There are a lot of crappy GUIs out there as well, which would have been better served as CLI tools (in my subjective opinion). And what is "IS NOT meant for fancy user interfaces" supposed to mean? (and what about various constraints back in the day as the actual reason for a data in/data out-only interface as opposed to "intent"?) I could argue that tmux is "fancy", since it is a multi-panel workspace, mirroring GUI capabilities, but apparently that's Ok according to you. So your conclusion seems to be that TUIs are actually ok in general - you just don't like bad/over designed interfaces (subjective terms, of course), which is understandable. Sorry, but I don't get your point. Bad interfaces are everywhere. (I kind of like fancy TUIs when they make sense, to be honest, so there's that)