Hacker News Reader

Comment by kragen | Hacker News Reader

sixel was more relevant then than it is now because a vt340 was still cheaper than a pc with a vga in it and the cpu time to decompress even a gif with lzw required a quite noticeable wait; jpeg wasn't even in the picture

now, if you want to display graphics from a remote server, your choices include webp over quic, jpeg over http, and h.264 over ssh, and raw pixels over x11, possibly lz77-compressed by forwarding over ssh -XC

sixel is an obviously terrible choice compared to any of those except that it forms part of your shell window, which is a pretty big plus; but i agree with you that in this day and age we should be able to come up with something better

View on HN

But do we need to do everything in your shell window? I made an alias to be able to show pictures from my kitty terminal...and almost never use it. I have a photo viewer on my laptop, why would I use the terminal for that?

If I want to show a single picture, it doesn't take longer to type eog <filename> [1] than my alias (icat), if I need to see thumbnails of more than one, it doesn't take longer to open my file manager. If the file is remote, the directory is mounted easily from my file manager or the command line.

[1] eye of gnome in my case

I use the terminal a LOT. Makes sense to do it there. Especially because it works over SSH, it's a lot simpler than X Forwarding (especially since that is broken by wayland).

I am also working a lot with terminal but sometimes there are simply better tools for the job. Re: ssh but how about just mounting with ssh when media files are expected? If you want to play a sound file, you still have to find a way to transport audio anyway. It is just so much more convenient to mount the directory using sshfs or your file manager.

I guess most people who are afraid to get out of the terminal are those that are stuck with terrible window managers from macOS or Windows and don't know how to easily switch focus from one window to another and back in a pinch without using their mouse.

Lol I've never heard about people being afraid to get out of the terminal. In, yes :) Especially Windows and Mac users find the terminal (and the registry) very scary in my experience. I've even seen legit IT people that are super scared of changing values in the registry or plist/defaults on Mac. Though Windows admins are getting more used to it again now that MS is pushing PowerShell as a management tool so heavily (which makes sense, it's much easier to manage infrastructure as code)

I use both GUI and Terminal yes (KDE though because I hate Gnome's opinionated design :). I can control it fully with the keyboard but on a remote system I'd still prefer to do things inside the ssh session. Usually because I've jumped through different systems and forwarding it the whole way is a PITA. I never really use sshfs for this reason.

In fact no I rarely need to view pics either, it's just not really one of the things I would do on remote systems. But it's nice to have the ability if the need does arise.

take a look at how people use jupyter with graphics and sound integrated into their repl

https://www.youtube.com/watch?v=sL_FfWK6J2w

it'd be nice to have that when i'm sshing to a remote machine but without jupyter's janky scrolling

You can get most of the way there with euporie:

https://github.com/joouha/euporie

I don't support audio yet, but it should be possible using DECPS escape sequences

neat! glad to see it supports kitty's inline image interface

what do you think of the prospects for supporting smooth animation or mouse interaction with data visualizations? e.g., brushing or interactive rotation in 3d. in https://news.ycombinator.com/item?id=35951674 i was claiming that that isn't feasible within the constraints of extended vt100 emulation, but i'd love to be proven wrong

i'm also curious how kitty's protocol deals with unexpected output from a background process interleaved in the middle of an image

I've been doing some experimentation with this you might like to see:

https://blog.josiah.link/o/07dffc4ade3246f3a8edf6d7d5917b0c

I don't think a VT340 and a PC competed in the same category back then. A VT needed a serious minicomputer at the very least at a backend - PC-based Linux wasn't an option yet.

It was just something dependent on a core choice of what kind of computing you wanted in your business (centralised minicomputer or distributed with PCs)

The applications those ran were also not compatible at all.

a pc running procomm plus made a pretty good terminal, and there were better emulators of the vt family than procomm if you needed that

and then you could also use the pc for some other things, like it could edit a text file more responsively, and without causing context switches on your vax and slowing it down for other users. even if moving the files back and forth over kermit was a bit of a pain, and the keybindings for tpu or edt weren't compatible with wordstar or brief or whatever you used on the pc

but yeah once you had pcs there was a strong temptation to move most of the computing onto them unless it wouldn't fit, even though prodos, ms-dos, system 7, etc., were diarrhea pie

Reply on news.ycombinator.com