VT330/VT340 Sixel Graphics

Yes the spinners that are made of braille are nice. And graphs.

But unicode support is pretty ubiquitous now. It works great. Despite advanced unicode (ligatures, emoji) not really playing nice with monospaced fonts, most terminals handle it very well.

By the way yes it's relatively popular, out of the various options. Sixels are more popular than Kitty's protocol and what iTerm2 has.

Though more and more console libraries are supporting multiples of these which will help get more reach for all of them.

> they were novel but they weren't actually good. that goes double for sixel: it was pretty cool to see the system manager loading a color image on his vt340+ but we're talking about a postage stamp per second. you could see the individual color planes loading

Yeah that was my point. It was so slow it was really only usable for the usecases bringing extreme value. A vector drawing protocol like tectronix (still included in xterm also) would have been preferable.

> the vt340 was a misguided engineering dead end. i think even the vt100 was a mistake, given that they had to put an entire computer inside of it to make it work, and it would have been a lot nicer to rethink how terminals could work in light of the new possibilities opened up by vlsi

The VT340 yes. I don't think the VT100 was a dead-end. It wasn't the most popular terminal of its day for nothing. This was the time when microprocessors started powering everything from microwaves to fridges. A "whole computer" was still simpler than the VT05 which had no "computer" but a whole stack of PCBs full of discrete electronics.

See how horribly deep it was to house all those electronics: http://terminals-wiki.org/wiki/index.php/File:DEC_VT05_12170... . And despite all that its terminal protocol was super basic, it wasn't a lot more than a screen-based teletype. I think it's one of the most beautiful designs of the day though. Very star trek.

The VT100 was a computer yes (there was actually a standalone CP/M version of it called the VT180). But it didn't really compete with PCs, it was a logical choice if you had a centralised minicomputer which was still very common back then. Being 'cheap' was relative only to the central computer which was a huge investment.

And of course its successors were way cheaper and smaller (the VT220 and VT320 in particular). I think the 320 was a really nice form factor, the 220 still had fairly chunky bezels.

I still own a VT520 myself but it has a distinct "generic VGA monitor" feel. It is the most capable of the range for using it in this day and age though (which doesn't mean a lot, a lot of *nix software these days just blasts xterm without bothering to check termcap or terminfo).

this would be wonderful

I cannot find waypipe in any package for the OS on the closest machine using Wayland.

> Was this reply intended for a comment?

No, I'm just asking why there's interest around Sixel when there are protocols (like iTerm's Inline Images Protocol) that use standards-based image formats.

I'm not a heavy terminal user and don't see much value for images in my CLI, so one very possible explanation is that I don't understand the use cases where this "interesting" format (without a guaranteed pixel aspect ratio, as I understand it) shines.

That's very helpful to know, thanks! So Sixels are a reasonably-popular de facto standard already, which I did not understand.

I know that at least Konsole, mlterm (which I use), and wezterm support iTerm's method.

Unfortunately iTerm's method does not have a googlable name like ‘sixel’.

When this tech was invented it was less relevant than it is now. For the following reasons:

- 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.

you seem to be attempting to define 'terminal' as 'vt100 emulator', which unfortunately condemns you to only unreliable solutions like sixel that are too inefficient to provide smooth graphical interaction and full of compatibility problems. you can plot a graph from a remote machine, sure, but if you want to use your mouse to zoom in on it, you just bought a one-way ticket to jank city

but i've used graphical terminals like ncd x terminals since 01994, and they provided smooth graphical interactions even over shared 10-megabit ethernet. current xorg and xwayland do a great job of emulating those terminals, with most of their deficiencies fixed, and ssh has built-in support for transparently passing along the needed credentials

xpra works even better, supporting h.264 compression and reattaching to applications you've detached from

the big problem with x11 is that trying to write a program to do something simple like display an image or draw a bar graph ensnares you in five pages of bureaucracy

to solve that problem i wrote yeso: https://gitlab.com/kragen/bubbleos/blob/master/yeso

here's a program to display a png with yeso:

    #include <yeso.h>

    int main(int argc, char **argv)
    {
      ypic img = yp_read_png(argv[1]);
      if (!img.p) return 1;
      ywin w = yw_open(argv[1], img.size, "");
      yp_copy(yw_frame(w), img);
      yw_flip(w);
      for (;;) yw_wait(w, 0);
    }

it also runs on the linux framebuffer without x-windows

here's a color generalization of munching squares in yeso in python:

    import yeso


    def munch(t, fb):
        for y, p in enumerate(fb):
            for x in range(fb.size.x):
                p[x] = (t & 1023) - ((x ^ y) & 1023)

    if __name__ == '__main__':
        with yeso.Window(u"CPython μunching", (256, 128)) as w:
            t = 0
            while True:
                with w.frame() as fb:
                    munch(t, fb)
                t += 1

it uses python context managers so you don't forget to yw_flip()

there's also a luajit binding

the example programs above are non-interactive, like virtually everything sixel that isn't full-screen; here's a lua program to test mouse interaction:

    local yeso = require 'yeso'

    function bounds(a, b)
       if a < b then return a, b else return b, a end
    end

    yeso.Window("mΩuso", {256, 256}):run(function (w)
          local m, dragStart = {x=128, y=128}
          while true do
             for ev in w:events() do
                if ev.isMouse then
                   m = ev.p
                   if ev:button(1) and dragStart == nil then
                      dragStart = {x=ev.p.x, y=ev.p.y}
                   elseif not ev:button(1) then
                      dragStart = nil
                   end
                end
             end

             w:frame(function (f)
                   f:fill(0x7f7f7f)

                   if dragStart then
                      local minX, maxX = bounds(dragStart.x, m.x)
                      local minY, maxY = bounds(dragStart.y, m.y)
                      f:sub({minX, minY}, {maxX-minX, maxY-minY}):fill(0x336699)
                   end
             end)

             w:wait()
          end
    end)

as for embedding interactive graphics in a text stream, i'm still trying to figure out the bubbleos solution to that. but i'll get there, and the result will be usable over ssh, while sixel probably hasn't gotten there even for low-bandwidth interactive localhost cases and probably never will

ssh has supported x11 forwarding since at least 01996, and i've frequently forwarded vnc over it as well

i think the problem here is that x11 is shitty at 'inline' (things tend to open annoying new windows) and a modern terminal cosplaying a vt100 is shitty at graphics

sixel doesn't solve that problem; your terminal emulator is still shitty at graphics

that's an interesting approach

i think you could probably get pretty far by creating a new x11 socket with fresh xauth for each new program launched; then, instead of opening new floating overlapping windows for them, embedding the display of whatever windows they create in your notebook, just below below the command that created them

a bytestream protocol has some real advantages, including being able to forward it over a network socket, including an ssh-forwarded socket, or providing a gui for whatever little embedded electronic gadget you build and connect to your terminal over spi or usb serial

i had previously rejected it as too inefficient for the localhost use case, but in https://news.ycombinator.com/item?id=35693474, and some later protocol-design ideas i haven't shared yet, i convinced myself that you can probably make it efficient enough for anything that doesn't use custom shaders

is this something you'd be interested in talking about in a less hostile environment