3 ms·
Those existing tools are poorly designed, if you read the article it has a link to the discussion about its design choices, which contains in turn discussion ab
by aumerle 3y ago
Those existing tools are poorly designed, if you read the article it has a link to the discussion about its design choices, which contains in turn discussion about all the problems with sixel https://github.com/kovidgoyal/kitty/issues/33#issuecomment-274337064 https://github.com/kovidgoyal/kitty/issues/33#issuecomment-2...
- rbanffy 3y agoI have been part of these discussions, mostly on the VTE side, as I made a promise to implement something that I'm yet to be able to deliver upon.
- unconed 3y agoThe linked spec in the original has all the hallmarks of "oh wait, maybe we do need...". It reads like what you get when someone has a poor idea of what 2D UI requirements are (alignment, relative positioning, layout, out-of-band image delivery, updates, animation, ...) and then has to retroactively fit them in one by one. And then the mechanisms it has for doing so read like they are a poor fit for how you want to use them, requiring weird global bookkeeping/state, and sound like a nightmare without a proper API around it, abstracting it away. Aka reinventing all the lessons of 30 years of UI development from scratch. From what I remember sixel is _worse_ but that doesn't really change things.
- aumerle 3y agoOr instead it reads like someone thoughtfully came up with a minimal design and then iterated on that based on real world feedback for what is actually useful in this context. Your only actual complaints were "weird global state" and "no API". I look forward to seeing you design a protocol that involves two way communication between two unrelated entities that avoids some shared state between them. As for no API, this is a protocol specification. if you need an API so badly go browse NPM.