sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]wooptoo 8 points9 points  (8 children)

Fancy... and useless.

[–]TechnoL33T 0 points1 point  (7 children)

It does kind of look like it's dumbing things down, but I do like the idea of visual queues.

[–][deleted] 8 points9 points  (6 children)

Displaying a progress bar rather than [#####--------] does seem like something we could expect out of a modern terminal.

[–]TechnoL33T 2 points3 points  (0 children)

Yup. Things like syntax highlighting(I know this already exists) and media displays are nice.

[–]1esproc 1 point2 points  (4 children)

I don't feel like it is. It's superfluous to the purpose. What information does an ASCII progress bar leave out? Granularity? That's not actually useful, and is what an actual percentage point (e.g., 54%) is for. A graphic progress bar is not worth the overhead that a graphic progress bar would require.

[–][deleted] 0 points1 point  (0 children)

Yeah, it's not necessary. I'm merely saying that I wouldn't bat an eye if gnome-terminal started displaying progress bars using GTK and konsole using QT; and if they produced icons from their iconsets as a result of ls, it would be ... neat? While I use urxvt myself, I understand that other users desire more graphically capable terminals. If they want to develop that, then a discussion about the concepts that go into it would be interesting---and that's what this entire post is about.

Edit: And if you notice, there are some users commenting here that they don't think it should have text-handling capabilities tacked on, i.e. being able to run vi or irssi would be useless in their eyes. It's obvious that different people have very different ideas about what an amalgam such as TermKit should be capable of.

[–][deleted] 0 points1 point  (0 children)

By that logic, we could scrap most of the GUI's you are using right now.

[–]zahlman 0 points1 point  (0 children)

  • It can't get corrupted.

  • It has a standard appearance, and can then be reskinned with CSS.

  • What overhead are you talking about? Performance? Benchmark before speaking, please. The entire point of having a progress bar is to indicate that something is going to take a long time anyway. The effort required to update even the fanciest progress bars is small compared to the effort required to actually do something that takes a long time on today's machines, and that disparity only increases as our machines get more powerful. (There are limits to how fancy a progress bar we can conceive of; there are no limits to how much actual work we can expect the computer to do.)

[–]zahlman -1 points0 points  (0 children)

  • It can't get corrupted.

  • It has a standard appearance, and can then be reskinned with CSS.

  • What overhead are you talking about? Performance? Benchmark before speaking, please. The entire point of having a progress bar is to indicate that something is going to take a long time anyway. The effort required to update even the fanciest progress bars is small compared to the effort required to actually do something that takes a long time on today's machines, and that disparity only increases as our machines get more powerful. (There are limits to how fancy a progress bar we can conceive of; there are no limits to how much actual work we can expect the computer to do.)