no, sixel for terminals is a terrible idea. there is no universe in which it ever made sense, but it's an even worse design now than when it was new. (sixel for printers was, by contrast, a good idea)
sending raw, uncompressed pixels over a bytestream to display them on a monitor is reasonable sometimes, but never packed six bits per 8-bit byte, and certainly not with an extra start and stop bit. sending uncompressed pixels over a network is basically never a good idea; you should always compress them with at least zstd. when you're running over a network with possible packet loss, a guaranteed-delivery bytestream of pixels (compressed or otherwise) is only a reasonable idea for applications like displaying a static image; for displaying a gui you don't want to retransmit old frames of video that have been corrupted by packet loss, you want to discard them and display the current state of the stream, the way netflix does. xpra works that way, mosh works that way, and x11 should have worked that way, but didn't
sending pixels over a unix pseudo-tty is an even worse idea, because asynchronous output from background processes will corrupt your screen image and, in many cases, go unnoticed
vnc is a bytestream protocol for viewing a remote gui, and you can implement a minimally working vnc server in 300 lines of golang (http://canonical.org/~kragen/sw/dev3/vncs.go). multiple people can connect terminals to the same remote gui at once, you can disconnect and reconnect later (as with mosh and xpra), it's generally reasonably efficient, and although it does uselessly retransmit outdated pixel data in the face of packet loss, it gracefully handles the situation where there are too many screen updates to transmit to the terminal. you could do better than vnc but there's no reason to do worse
the blit terminal protocol and mgr are two somewhat more reasonable approaches to extending traditional serial terminal i/o to support full graphical interaction
sixel in dumb terminals was always a stupid idea because, if your terminal is smart enough to have a color framebuffer to decode the sixel data into, it's smart enough to run a more reasonable protocol than sixel. like, it can run tcp/ip and x11. dec was desperately trying to keep people from fleeing from the hierarchical world of the vax controlling a bunch of dumb terminals to the world where everybody had a computer of their own, but obviously it didn't work
sixel between two processes on the same system is even stupider. seriously, just put the uncompressed image in a shared memory buffer or a file. you can even use inotify to get asynchronously notified when the file has changed if you want. there's no point in encoding and decoding the image with some kind of shitty 01980s kludge designed to run over a 9600-baud rs-232 cable
i mean obviously if you want to write games in brainfuck or display graphics with sixel or whatever there's nothing wrong with that. but it's important to keep in mind that sixel belongs to the set of things that people do because they make easy things hard, not the set of things that people do because they make hard things easy
Regarding sixels: a bad standard is still better than no standard at all, a better terminal protocol for a pixel framebuffer, controllable via ASCII sequences would indeed be a good thing.
> it's smart enough to run a more reasonable protocol than sixel. like, it can run tcp/ip and x11.
...at the cost of an incredibly bloated software stack. Sixels just need the equivalent of a VGA framebuffer and would also work on Linux installations that don't boot into a windowing system.
ascii terminals don't support anything that looks better than ascii art. they don't support sixel either. there are a variety of proposals for how to add graphics to ascii terminal emulators in a backwards-compatible way, such as mgr and notty https://github.com/alacritty/alacritty/issues/51 but they all suffer from some of the same problems as sixel
but the 'terminal' that a terminal emulator is emulating is a device which provides a user access to a remote computer. it is called a 'terminal' because it is at the end of a long wire connecting it to the computer (perhaps through a network). normally nowadays this is a laptop or cellphone. in that case, yes, you can use x-windows, xpra, vnc, rfb, spice, or a web browser
well, you can't display mpv videos in your terminal emulator with sixel graphics or any other kind of graphics if your terminal emulator is running in an environment doesn't support graphics, such as if it's displaying on an adm3a. perhaps you mean you don't want your terminal emulator to run inside a window manager. well, the x server and the wayland server don't run under a window manager; the window system runs under them, if it runs at all
That's exactly the point. Why can't you? Because no one implemented that support in that terminal emulator? Or it's impossible for some reason?
I get the reason of may be kernel not wanting to overload the minimalist terminal with features due to security concerns and etc, but as the article suggests, it can be moved out of the kernel, so I don't see why it shouldn't be doable.
i said you can't 'if your terminal emulator is running in an environment doesn't support graphics, such as if it's displaying on an adm3a'. that is because the adm3a hardware physically cannot draw any graphics
yes, that was why i was trying to clarify what you meant by 'without graphics environment'; whether you meant a window manager (which i'd already given several suggestions for) or an environment capable of supporting graphics (in which case you've made the problem insoluble)
shared memory is, by contrast, an extremely reasonable way to get pixels into your user interface (i was going to say 'terminal' but it doesn't really make sense in this context)
sending raw, uncompressed pixels over a bytestream to display them on a monitor is reasonable sometimes, but never packed six bits per 8-bit byte, and certainly not with an extra start and stop bit. sending uncompressed pixels over a network is basically never a good idea; you should always compress them with at least zstd. when you're running over a network with possible packet loss, a guaranteed-delivery bytestream of pixels (compressed or otherwise) is only a reasonable idea for applications like displaying a static image; for displaying a gui you don't want to retransmit old frames of video that have been corrupted by packet loss, you want to discard them and display the current state of the stream, the way netflix does. xpra works that way, mosh works that way, and x11 should have worked that way, but didn't
sending pixels over a unix pseudo-tty is an even worse idea, because asynchronous output from background processes will corrupt your screen image and, in many cases, go unnoticed
vnc is a bytestream protocol for viewing a remote gui, and you can implement a minimally working vnc server in 300 lines of golang (http://canonical.org/~kragen/sw/dev3/vncs.go). multiple people can connect terminals to the same remote gui at once, you can disconnect and reconnect later (as with mosh and xpra), it's generally reasonably efficient, and although it does uselessly retransmit outdated pixel data in the face of packet loss, it gracefully handles the situation where there are too many screen updates to transmit to the terminal. you could do better than vnc but there's no reason to do worse
the blit terminal protocol and mgr are two somewhat more reasonable approaches to extending traditional serial terminal i/o to support full graphical interaction
sixel in dumb terminals was always a stupid idea because, if your terminal is smart enough to have a color framebuffer to decode the sixel data into, it's smart enough to run a more reasonable protocol than sixel. like, it can run tcp/ip and x11. dec was desperately trying to keep people from fleeing from the hierarchical world of the vax controlling a bunch of dumb terminals to the world where everybody had a computer of their own, but obviously it didn't work
sixel between two processes on the same system is even stupider. seriously, just put the uncompressed image in a shared memory buffer or a file. you can even use inotify to get asynchronously notified when the file has changed if you want. there's no point in encoding and decoding the image with some kind of shitty 01980s kludge designed to run over a 9600-baud rs-232 cable
i mean obviously if you want to write games in brainfuck or display graphics with sixel or whatever there's nothing wrong with that. but it's important to keep in mind that sixel belongs to the set of things that people do because they make easy things hard, not the set of things that people do because they make hard things easy