4 ms·
> 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
by 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 agoWhat 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 agoWhile 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 agoWith 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 agoAbsolutely 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 agoAgain, 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.