Using gnuplot is a nice idea, but the protocol doesn't play nice with other terminals that don't support inline images. See what iTerm2 is doing along these lines. http://www.iterm2.com/images.html
The ReGIS support is nice, but with the custom functionality it would be nice if instead of echoing an ASCII string like "HTERMFILEXFER" it used actual escape sequences.
Terminology[1] does this correctly with its own escape sequences. But, unfortunately, it doesn't actually use the escape sequences to transfer file data, even though it could. Instead it just transfers URLs, which isn't as network-transparent as I would like.
(Background: I did some research a couple of months ago into what it would take to build a graphical terminal emulator, to support a backwards-compatible network-transparent TermKit[2]-like experience.)
(Edit: Apparently the latest nightlies of iTerm2 also supports this sort of functionality, and does so properly with escape sequences.[3] Thanks, gnachman.)
Yes, it would be better to use escape sequences. If I remember correctly there were issues with terminal multiplexers stuffing data into the stream. So you'd need something smart serverside to escape each chunk.
In the current implementation, the server can be pretty dumb (i.e. all you need is a bash script). This was a requirement for me, because I spend a lot of time jumping between different Linux boxes which aren't configured as I might like them to be (in particular I wanted something that work when bouncing though odd ssh gateways etc).
So overall, the png rendering is intended as a quick hack, for when you want to render data quickly. As a proper inline rendering solution, it would be nice to add support for Sixels (http://en.wikipedia.org/wiki/Sixel) or something similar. If you google around I think there are a few terminals that support that, but none of them suited my requirements.
Overall, I was kind of happy with the code as a proof of concept, and still use the iOS version every day (it's a free iOS ssh client and does all the graphical support stuff). There's a lot that could be done though. Ideally I'd like to abstract out the ReGIS code, add Sixels support and then integrate that code into existing Linux and OSX terminal apps.
The old school part of me who had to use gnuplot with tek40xx emulation because that's all we had for graphics kinda loves seeing this. Then the 2014 me is thinking/shouting "Why? Working with graphics terminals really sucked back then."
It's mostly just a side project. I spend a lot of time, sshing though various boxen and then needing to quickly plot of results of an analysis. I wanted a solution to quickly dump a plot rather than often having to upload them somewhere and download again to view.
Why not just have a terminal that renders html? It would probably need a nontrivial amount of work to specify exactly how input will be handled, or how DOM events will work, but it sounds as something interesting to try.
13 comments
[ 6.1 ms ] story [ 48.7 ms ] threadTerminology[1] does this correctly with its own escape sequences. But, unfortunately, it doesn't actually use the escape sequences to transfer file data, even though it could. Instead it just transfers URLs, which isn't as network-transparent as I would like.
(Background: I did some research a couple of months ago into what it would take to build a graphical terminal emulator, to support a backwards-compatible network-transparent TermKit[2]-like experience.)
(Edit: Apparently the latest nightlies of iTerm2 also supports this sort of functionality, and does so properly with escape sequences.[3] Thanks, gnachman.)
[1]: http://www.enlightenment.org/p.php?p=about/terminology
[2]: http://acko.net/blog/on-termkit/ and https://github.com/unconed/TermKit
[3]: http://www.iterm2.com/images.html
In the current implementation, the server can be pretty dumb (i.e. all you need is a bash script). This was a requirement for me, because I spend a lot of time jumping between different Linux boxes which aren't configured as I might like them to be (in particular I wanted something that work when bouncing though odd ssh gateways etc).
So overall, the png rendering is intended as a quick hack, for when you want to render data quickly. As a proper inline rendering solution, it would be nice to add support for Sixels (http://en.wikipedia.org/wiki/Sixel) or something similar. If you google around I think there are a few terminals that support that, but none of them suited my requirements.
Overall, I was kind of happy with the code as a proof of concept, and still use the iOS version every day (it's a free iOS ssh client and does all the graphical support stuff). There's a lot that could be done though. Ideally I'd like to abstract out the ReGIS code, add Sixels support and then integrate that code into existing Linux and OSX terminal apps.
- https://chromium.googlesource.com/apps/libapps/+/master/hter...
- https://chromium.googlesource.com/apps/libapps/+/master/nass...
- https://groups.google.com/a/chromium.org/d/forum/chromium-ht...
Good job at the download links too, I had a good laugh.