sixel graphics support?

[hackerb9]

Hi! I'm the author of `lsix` (ls for images) which requires sixel graphics to work. I just got a bug report that terminator is supposed to have libsixel support but my program doesn't show anything. https://github.com/hackerb9/lsix/issues/28

It seems terminator is not sending the device attribute code one would expect to receive from a sixel capable terminal. (lsix is lookings for a 4 in response to $'\e[c').

Can you please clarify: does terminator support sixel graphics?
If so, which version of terminator do people need?
If not, is sixel in the works or planned for the future?

Thanks!

[Egmont Koblinger (egmont-gmail)]

_This_ terminator uses VTE for terminal emulation, which does not support sixel, and is not planned. See https://bugzilla.gnome.org/show_bug.cgi?id=729204 for details and rationale.

There's another terminal also called terminator, though, maybe your bug's OP mixed up the two.

[hackerb9 (hackerb9)]

Another Terminator? Is this one from the future as well? I'll ask my bug's OP.

Do you know if that bug you linked is still the stance of VTE? It seems a bit outdated and a little bit of "the perfect being the enemy of the..." — well, I can't call sixels "good" — "of the good enough". The bug speaks of not being able to read the cell size to position images, but that's easy with DTterm window ops. Also, there's mention of the problem of not resizing the image when the font size changes, but the image viewing program I use simply catches SIGWINCH and resends the image if needed. Also I notice that iterm2, the other terminal program they compare as having an alternate way to view images from within a terminal, has recently added sixel support.

Maybe the VTE folks have changed their minds by this point?

[Egmont Koblinger (egmont-gmail)]

> of the good enough

In my opinion, sixel is nowhere near good enough for today's standards.

> but the image viewing program I use simply catches SIGWINCH and resends the image if needed

There's a lot more to this story, and I'm not going to go into the details _again_, sigh. E.g. what if it's not an app that keeps running refreshing its screen, but one that prints the image once (like an "ls") and then quits? Who is going to specify and implement the behavior of the terminal's data buffer in a robust, non-crashing way if the text flow and the image within live separate lives during a resize; adding gap, or moving them closer to each other so that they overlap – let alone what a crappy user experience this is? Also what about plenty of other things, like, tmux-ability, being able to crop the image by the terminal? There's a _lot_ more to this extremely complicated story.

> Maybe the VTE folks have changed their minds by this point?

VTE folks is two people at this moment, one of them is me, and I haven't changed my mind. I'd love to support a _good_ image protocol, which sixel is not.

[hackerb9 (hackerb9)]

> VTE folks is two people at this moment, one of them is me, and I haven't changed my mind. I'd love to support a _good_ image protocol, which sixel is not.

I won't try to change your mind. I also see the numerous flaws in the sixel protocol, and if there was anything better out there, I'd use it.

Feel free to ping me if VTE ever supports inline graphics of any form and I'll see if I can add support to `lsix`.

Thanks!