exquo
commented
2 years ago Would be neat, but the graphics-in-terminal situation is, in general, more of a hack than a reliable solution. Each of sixel, w3m-img, kitty and iterm methods work on different subsets of the existing terminal emulators and don't always play nice with tmux, compositing window managers, etc.
We could allow the users to specify the command for viewing images that works on their system, like ranger's preview_images_method. But what type of data output / action produced should result from such process call, and how can we use it in scli?
The issue is, these tools draw directly in the terminal framebuffer (except perhaps for the ones that use Unicode half-blocks to produce a "blocky" image). whereas scli gives the control of writing anything on the screen to urwid. There is an urwid.Terminal widget that allows to embed a terminal into an urwid program, but the likelihood of the graphics rendering correctly inside it is even lower than for a regular terminal emulator.
In principle this should be possible - ranger and w3m can do this - although urwid might require a patch first. But TBH, I wouldn't want to be the one going down this rabbit hole :). Of course, any pointers on how this can be accomplished easier are appreciated!
maximbaz
It would be interesting to be able to display images directly in the chat, if a terminal supports this.
For example, kitty has developed a graphics protocol, that is supported by several apps and also at the moment of writing one other terminal application:
https://sw.kovidgoyal.net/kitty/graphics-protocol/
What do you think about it?