SIXEL support.

[vifino]

There is a patch floating around of questionable quality:
https://gist.github.com/saitoha/70e0fdf22e3e8f63ce937c7f7da71809

I'm tempted to try and implement/port it to xst.
Thoughts?

It'd be handy for a couple things.

[actionless]

it seems what it doesn't require too much modification of xst.c itself so it shouldn't affect the readability of overall app much since most of the new logic is implemented in separate files

however to make it easier to port the patch i think first it would be better to backport to xst st refactoring about extracting some stuff from st.c to win.h and x.c

[vifino]

Can you elaborate the second part of your comment?

Is there another patch/change that needs to be ported to xst or a change made to xst that conflicts with the patch?

If all else fails, I'll reimplement SIXEL support.

[actionless]

take a look on filelist of st vs xst

xst was forked from st back then when st was a single file, now it's splitted into multiple files (win.h and x.c)

[actionless]

btw, sorry for offtopic question, but where it could be used? i found only lsix script, which tries to implement ls with thumbnails via using montage

i think if you'll give more real usecases for the feature you could motivate more people to collaborate on it :-)

[vifino]

well, i was hoping to use ff2sixel to display images, graphs and such.
i have some led matrix code which i'd love to make a sixel output for as well, so that i can debug all in my terminal.

[halfwit]

https://github.com/uobikiemukot/sdump/ exists as well

[vifino]

@actionless just to make sure i don't get this wrong:
would you rather i keep xst in a single file backport to xst the st file split?

i am probably just gonna keep xst in a single file and redo the changes, it looks easier.
i am not sure how to do the latter without applying the changes manually.

[actionless]

my vote is for changing xst structure in a same way as st did (because generally i am up to having bigger number of smaller files rather than the opposite)

@neeasade @laserswald any opinion on this?

[neeasade]

Yes, it's been a lingering task for awhile now to revert to upstream file layout, both for the split and easier merges/updates from st in the future. Gets a little hairy doing that split while preserving xst changes and pulling, which is why it hasn't happened yet

[actionless]

also could be useful if somebody will be trying to tackle it later on: http://rullf2.xs4all.nl/sg/doc.html

[charlesdaniels]

Hi all, I'm not a xst user (I roll my own forked off from st directly), but I've successfully gotten the patch that the OP noted working on my st fork. It's pretty hacky - I had to move a lot of things around manually, and make a lot of things global between x.c and st.c, however, my implementation does seem to more or less work.

link to my st fork

Please feel free to use any of my code as a starting point if you would like.

Do note that the patch from the OP likely infects any code that uses it with GPL, as the sixel decoder is taken from (IIRC) mintty. If this bothers you, you may want to roll your own decoder, or use libsixel instead.

If you make any improvements to the sixel support, please let me know so I can merge them back into my own implementation :)

~ Charles

[actionless]

oh, thanks for your good point about the license, @charlesdaniels. didn't noticed it initially

anyway i think the progress on sixel is frozen until somebody will be not lazy enough to split the files in a same way as in st :-)

FYI - I have done a fair amount of sixel work in the last couple years, and made some torture tests available for terminal authors here: https://jexer.sourceforge.io/sixel.html .

[pfr-dev]

I'd just like to add that I'm keen for this and also came across the st-sixel fork which is still a little old but could be worth a look for inspiration.