- It required special expensive terminals, the VT330 (mono) or VT340. Those were not ubiquitous, the VT320 was the bread and butter type. Later VTx20 models also didn't gain support for it (usually the lower range models got premium features from the previous ranges like multiple connections / pages but this one didn't 'trickle down'). So there wasn't so much incentive for developers to support it as the installed base was very low.
- It required a long time to send all the information, because terminals were still on slow serial connections. The VT320 could only do up to 19200 bps which was not even super fast for text at 80x25! Sixel images would take ages to transfer. Even though we had different expectations of response speeds then, sixels were slow by the standard of the day.
- Colour highlighting (or even monochrome "bold"/ultrabright) was not even common in most commandline tools back then, even LS. Hell, on HP-UX in the 90s I couldn't even use the cursor keys in the default shell for command history and line editing! Mod cons we take for granted now were yet to be invented then.
- Thumbnail processing as the parent suggests would take a lot of space and processing speed. My quota at college was a few megabytes. In fact I hardly had any images. I think I had just one, a nice Enterprise-D render that I used as wallpaper. It's not like we had thousands of images to sift through like we do today. Of course the web changed that rapidly but at that time text terminals were already on the way out.
Some apps used it for stuff that was worth the wait. Like the print preview in word perfect. But many apps didn't bother because the above constraints just made them infeasible. Sixels only really took off after their original terminals were long gone. And really in this day and age we should be able to come up with something better.
now, if you want to display graphics from a remote server, your choices include webp over quic, jpeg over http, and h.264 over ssh, and raw pixels over x11, possibly lz77-compressed by forwarding over ssh -XC
sixel is an obviously terrible choice compared to any of those except that it forms part of your shell window, which is a pretty big plus; but i agree with you that in this day and age we should be able to come up with something better
It was just something dependent on a core choice of what kind of computing you wanted in your business (centralised minicomputer or distributed with PCs)
The applications those ran were also not compatible at all.
and then you could also use the pc for some other things, like it could edit a text file more responsively, and without causing context switches on your vax and slowing it down for other users. even if moving the files back and forth over kermit was a bit of a pain, and the keybindings for tpu or edt weren't compatible with wordstar or brief or whatever you used on the pc
but yeah once you had pcs there was a strong temptation to move most of the computing onto them unless it wouldn't fit, even though prodos, ms-dos, system 7, etc., were diarrhea pie
If I want to show a single picture, it doesn't take longer to type eog <filename> [1] than my alias (icat), if I need to see thumbnails of more than one, it doesn't take longer to open my file manager. If the file is remote, the directory is mounted easily from my file manager or the command line.
[1] eye of gnome in my case
I guess most people who are afraid to get out of the terminal are those that are stuck with terrible window managers from macOS or Windows and don't know how to easily switch focus from one window to another and back in a pinch without using their mouse.
I use both GUI and Terminal yes (KDE though because I hate Gnome's opinionated design :). I can control it fully with the keyboard but on a remote system I'd still prefer to do things inside the ssh session. Usually because I've jumped through different systems and forwarding it the whole way is a PITA. I never really use sshfs for this reason.
In fact no I rarely need to view pics either, it's just not really one of the things I would do on remote systems. But it's nice to have the ability if the need does arise.
https://www.youtube.com/watch?v=sL_FfWK6J2w
it'd be nice to have that when i'm sshing to a remote machine but without jupyter's janky scrolling
https://github.com/joouha/euporie
I don't support audio yet, but it should be possible using DECPS escape sequences
what do you think of the prospects for supporting smooth animation or mouse interaction with data visualizations? e.g., brushing or interactive rotation in 3d. in https://news.ycombinator.com/item?id=35951674 i was claiming that that isn't feasible within the constraints of extended vt100 emulation, but i'd love to be proven wrong
i'm also curious how kitty's protocol deals with unexpected output from a background process interleaved in the middle of an image