4 ms·

While I sympathize with the needs of accessibility, personally I want to head in the complete opposite direction. Give me a terminal with actual graphics alrea

While I sympathize with the needs of accessibility, personally I want to head in the complete opposite direction. Give me a terminal with actual graphics already. Like why is htop drawing stuff with | characters? Use actual pixels, it'll look prettier! We do actually have some capability to do terminal graphics with for instance kitty, but pretty much nothing uses it. But it can be done, example: https://i.imgur.com/fHdkkLn.png https://i.imgur.com/fHdkkLn.png Done smartly, it could actually be more accessible. If we can somehow encode the knowledge "this graphic here is a progress bar at 30%", then we could have much more sensible output on TTS than for "[==== ]"

silvertaza 3y ago
I feel like we're in the extremes in both cases, where general customer interfaces are all super information sparse, and terminals are heavy on text. Having more visual terminals and more text UIs elsewhere would be best of both worlds.
alpaca128 3y ago
> Use actual pixels, it'll look prettier! No, thanks. My problem with such ideas is not the feature itself but the fact that UI tooling always aims to make use of the medium's full potential, and applications then always follow suit. The only reason we don't have animation frameworks for the terminal is because it's not possible, and I'd like it to stay that way. More accessibility would be great but you don't need pixels for that either. Better than images & pixels in the terminal would be a GUI platform that is as simple to use and integrate as the terminal and still feels natural to use with the keyboard. And has a toggle for animations.
- andersa 3y ago
  What do you mean? Animating the terminal is totally possible!
- xg15 3y ago
  "Better than images & pixels in the terminal would be a GUI platform that is as simple to use and integrate as the terminal and still feels natural to use with the keyboard. And has a toggle for animations." This. What I'd really like is some sort of simple API/structured data standard that tools could implement and then a "generic technical UI" which can automatically generate a UI for that tool. (the UI doesn't have to be pretty or fancy, as long as it lets me quickly and effectively make use of the tools). I think REST endpoints with an OpenAPI definition that automatically lets you generate an HTML documentation with built-in API client goes a bit into that direction. As did Microsoft's idea of "commandlets" I believe. As, actually, did HTML+HTTP in its original inception. However, so far all of those massively fall short in the "allow effective use of the tool" metric: For actual work, it's still way faster and more convenient to make a REST call via curl (once you figured out how to assemble the call!) - than to click around in the OpenAPI client. But maybe some future tool/standard could bring something better to the table here.
- actualwitch 3y ago
  > The only reason we don't have animation frameworks for the terminal is because it's not possible https://nick-black.com/dankwiki/index.php/Notcurses https://nick-black.com/dankwiki/index.php/Notcurses
- dvfjsdhgfv 3y ago
  While I agree with your post in general, this is not true: > we don't have animation frameworks for the terminal is because it's not possible We've had AAlib for 3 decades already: https://en.wikipedia.org/wiki/AAlib https://en.wikipedia.org/wiki/AAlib - and it's not the only game in town.
  - alpaca128 3y ago
    With animation I mean UI animation, like smooth opening of a menu etc. That is obviously not possible because it would require a much higher resolution. That is generally the kind of animation I dislike as it almost always comes with no real benefit while slowing down user interactions.
    - dale_glass 3y ago
      Absolutely possible. There are DOS programs that did it, but the name escapes me right now. But things like smoothly opening a menu are doable by just adding line by line, and dialogs can be animated by doing an animation that expands a window from the center.
    - dvfjsdhgfv 3y ago
      > With animation I mean UI animation, like smooth opening of a menu etc. But we definitely did have it in the 90s: https://www.youtube.com/watch?v=2EebJ4dN37M https://www.youtube.com/watch?v=2EebJ4dN37M
      - alpaca128 3y ago
        Again, I said "smooth" animation. Yes, it's kind of obvious that rendering movement is possible in the terminal as long as it can update the screen fast enough, but it feels pretty laggy at lower speeds because of the lack in precision. When people implement animations on UI elements they do it because it feels fluid, that's why terminal text editors aren't known to have smooth scrolling for example.
eviks 3y ago
Maybe the next gen of terminals that use structured data instead of dumb text could achieve that
- dale_glass 3y ago
  We can kinda have that already, it's just non-standard and rarely used. Here's for instance neofetch with actual graphics: https://i.imgur.com/fHdkkLn.png https://i.imgur.com/fHdkkLn.png
- vidarh 3y ago
  If your terminal exposes an API screen readers could access, there's nothing stopping it from defining escapes to allow you to assign aria roles, etc. to spans of text. But there's a bit of a chicken and egg problem there - you need a terminal to expose it, and a screen reader to support it before there's any benefit for any applications in adding it. One way of pushing some support for that, though, might be that if terminal apps annotates their output, it also opens the door for selectively letting users override presentation of it.
coldtea 3y ago
>Give me a terminal with actual graphics already. Like why is htop drawing stuff with | characters? Use actual pixels, it'll look prettier! That is exactly what we want to avoid. It begins with looking "prettier" and ends with "terminal apps" which 20 acres of whitespace around elements, and follow whatever the design fashion of the day is... And of course UX designers and wannabees get involved, and, it being much easier to bikeshed than code, our cli apps get redesigned every year like Gnome/KDE.
- dale_glass 3y ago
  I mean mainly things like this: https://github.com/aristocratos/btop/blob/main/Img/alt.png https://github.com/aristocratos/btop/blob/main/Img/alt.png Great work, it looks amazing! But what's the point of going through all the pain of rendering graphs in text? At that point, give me an actual graph. The code will be less messy and the information display will be better.
  - coldtea 3y ago
    >But what's the point of going through all the pain of rendering graphs in text? Embracing the curses interface constraints and limiting yourself on purpose to express just what you need to show - as opposed to getting sidetracked by the billions of possibilities of things to render and the shiny graphics? "This cpu is ~80% this is ~25% load" shown with representative bars for a quick visual gauging of the machine's state at a glance. Would it give it any more benefit it it had nice ticks, and fine gradations, and fancy rendering, so that you could tell 78% vs 80% more easily? It's not like GUI apps don't exist.
    - dale_glass 3y ago
      > "This cpu is ~80% this is ~25% load" shown with representative bars for a quick visual gauging of the machine's state at a glance. Would it give it any more benefit it it had nice ticks, and fine gradations, and fancy rendering, so that you could tell 78% vs 80% more easily? Yes. For instance the more cores you have the less room there is to draw a sensible graph, and we're up to 256 threads already. Even less enormous machines are already at the point where text is constaining. > It's not like GUI apps don't exist. Yeah, but SSH is great and not everything has good remote management. And I want the command line to keep up, not to be the better than nothing option.
vidarh 3y ago
htop is not drawing things with "|" unless it has to. It's using the boxdrawing characters. If that's not pixel perfect at all scales, it's your terminals problem, not htop (quite a few terminals have custom code to render the box drawing characters exactly to ensure they still join up and look like the appropriate box elements at all scales).

silvertaza 3y ago

I feel like we're in the extremes in both cases, where general customer interfaces are all super information sparse, and terminals are heavy on text. Having more visual terminals and more text UIs elsewhere would be best of both worlds.

alpaca128 3y ago

> Use actual pixels, it'll look prettier! No, thanks. My problem with such ideas is not the feature itself but the fact that UI tooling always aims to make use of the medium's full potential, and applications then always follow suit. The only reason we don't have animation frameworks for the terminal is because it's not possible, and I'd like it to stay that way. More accessibility would be great but you don't need pixels for that either. Better than images & pixels in the terminal would be a GUI platform that is as simple to use and integrate as the terminal and still feels natural to use with the keyboard. And has a toggle for animations.

andersa 3y ago
What do you mean? Animating the terminal is totally possible!
xg15 3y ago
"Better than images & pixels in the terminal would be a GUI platform that is as simple to use and integrate as the terminal and still feels natural to use with the keyboard. And has a toggle for animations." This. What I'd really like is some sort of simple API/structured data standard that tools could implement and then a "generic technical UI" which can automatically generate a UI for that tool. (the UI doesn't have to be pretty or fancy, as long as it lets me quickly and effectively make use of the tools). I think REST endpoints with an OpenAPI definition that automatically lets you generate an HTML documentation with built-in API client goes a bit into that direction. As did Microsoft's idea of "commandlets" I believe. As, actually, did HTML+HTTP in its original inception. However, so far all of those massively fall short in the "allow effective use of the tool" metric: For actual work, it's still way faster and more convenient to make a REST call via curl (once you figured out how to assemble the call!) - than to click around in the OpenAPI client. But maybe some future tool/standard could bring something better to the table here.
actualwitch 3y ago
> The only reason we don't have animation frameworks for the terminal is because it's not possible https://nick-black.com/dankwiki/index.php/Notcurses https://nick-black.com/dankwiki/index.php/Notcurses
dvfjsdhgfv 3y ago
While I agree with your post in general, this is not true: > we don't have animation frameworks for the terminal is because it's not possible We've had AAlib for 3 decades already: https://en.wikipedia.org/wiki/AAlib https://en.wikipedia.org/wiki/AAlib - and it's not the only game in town.
- alpaca128 3y ago
  With animation I mean UI animation, like smooth opening of a menu etc. That is obviously not possible because it would require a much higher resolution. That is generally the kind of animation I dislike as it almost always comes with no real benefit while slowing down user interactions.
  - dale_glass 3y ago
    Absolutely possible. There are DOS programs that did it, but the name escapes me right now. But things like smoothly opening a menu are doable by just adding line by line, and dialogs can be animated by doing an animation that expands a window from the center.
  - dvfjsdhgfv 3y ago
    > With animation I mean UI animation, like smooth opening of a menu etc. But we definitely did have it in the 90s: https://www.youtube.com/watch?v=2EebJ4dN37M https://www.youtube.com/watch?v=2EebJ4dN37M
    - alpaca128 3y ago
      Again, I said "smooth" animation. Yes, it's kind of obvious that rendering movement is possible in the terminal as long as it can update the screen fast enough, but it feels pretty laggy at lower speeds because of the lack in precision. When people implement animations on UI elements they do it because it feels fluid, that's why terminal text editors aren't known to have smooth scrolling for example.

eviks 3y ago

Maybe the next gen of terminals that use structured data instead of dumb text could achieve that

dale_glass 3y ago
We can kinda have that already, it's just non-standard and rarely used. Here's for instance neofetch with actual graphics: https://i.imgur.com/fHdkkLn.png https://i.imgur.com/fHdkkLn.png
vidarh 3y ago
If your terminal exposes an API screen readers could access, there's nothing stopping it from defining escapes to allow you to assign aria roles, etc. to spans of text. But there's a bit of a chicken and egg problem there - you need a terminal to expose it, and a screen reader to support it before there's any benefit for any applications in adding it. One way of pushing some support for that, though, might be that if terminal apps annotates their output, it also opens the door for selectively letting users override presentation of it.

coldtea 3y ago

>Give me a terminal with actual graphics already. Like why is htop drawing stuff with | characters? Use actual pixels, it'll look prettier! That is exactly what we want to avoid. It begins with looking "prettier" and ends with "terminal apps" which 20 acres of whitespace around elements, and follow whatever the design fashion of the day is... And of course UX designers and wannabees get involved, and, it being much easier to bikeshed than code, our cli apps get redesigned every year like Gnome/KDE.

dale_glass 3y ago
I mean mainly things like this: https://github.com/aristocratos/btop/blob/main/Img/alt.png https://github.com/aristocratos/btop/blob/main/Img/alt.png Great work, it looks amazing! But what's the point of going through all the pain of rendering graphs in text? At that point, give me an actual graph. The code will be less messy and the information display will be better.
- coldtea 3y ago
  >But what's the point of going through all the pain of rendering graphs in text? Embracing the curses interface constraints and limiting yourself on purpose to express just what you need to show - as opposed to getting sidetracked by the billions of possibilities of things to render and the shiny graphics? "This cpu is ~80% this is ~25% load" shown with representative bars for a quick visual gauging of the machine's state at a glance. Would it give it any more benefit it it had nice ticks, and fine gradations, and fancy rendering, so that you could tell 78% vs 80% more easily? It's not like GUI apps don't exist.
  - dale_glass 3y ago
    > "This cpu is ~80% this is ~25% load" shown with representative bars for a quick visual gauging of the machine's state at a glance. Would it give it any more benefit it it had nice ticks, and fine gradations, and fancy rendering, so that you could tell 78% vs 80% more easily? Yes. For instance the more cores you have the less room there is to draw a sensible graph, and we're up to 256 threads already. Even less enormous machines are already at the point where text is constaining. > It's not like GUI apps don't exist. Yeah, but SSH is great and not everything has good remote management. And I want the command line to keep up, not to be the better than nothing option.

vidarh 3y ago

htop is not drawing things with "|" unless it has to. It's using the boxdrawing characters. If that's not pixel perfect at all scales, it's your terminals problem, not htop (quite a few terminals have custom code to render the box drawing characters exactly to ensure they still join up and look like the appropriate box elements at all scales).