[HN Gopher] Show HN: Sixel-tmux displays graphics even if your t...
___________________________________________________________________
Show HN: Sixel-tmux displays graphics even if your terminal has no
Sixel support
Author : csdvrx
Score : 142 points
Date : 2021-10-05 08:19 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| eatonphil wrote:
| On a tangent, it would be awesome to have tmux for Windows
| Terminal without WSL (i.e. a native windows app). I've remapped
| Windows Terminal shortcuts to be like tmux bindings which gets me
| closer but it's still not the same.
| mkhnews wrote:
| tmux in mintty ?
| eatonphil wrote:
| Yeah that's an option but I can't stand Cygwin UX. tmux and
| mosh for native Windows would both be awesome.
| csdvrx wrote:
| Try sixel-tmux compiled with msys2 in Windows-Terminal:
| https://github.com/csdvrx/sixel-tmux/blob/main/tmux.exe
|
| Or compile it yourself using MinGW64 : after installing
| from msys2.org, pacman -S base-devel etc
|
| It works fine here. I have a Windows Terminal settings to
| start sixel-tmux instead of bash, using script to provide a
| pty: just have the command line be:
|
| C:/msys64/usr/bin/env.exe MSYS=winsymlinks:nativestrict
| MSYSTEM=MSYS /usr/bin/script -c /usr/bin/tmux /dev/null
| rashil2000 wrote:
| Wow, I'd been dying to make tmux work on WT. I couldn't
| get your tmux.exe executable to work (it froze WT, in
| both bash and cmd). However, the script method works!
| csdvrx wrote:
| I thought you might be having this issue, which is why I
| tried to be very explicit.
|
| It's due to a cygwin and how /dev/cons* are different
| from /dev/pty* cf
| https://cygwin.com/pipermail/cygwin/2020-May/244878.html
|
| I've tried to explain that a bit better in server-
| client.c (check line 251) to give the user a clue of
| what's happening with *cause = xstrdup(c->ttyname)
|
| Unfortunately, even in 2021, properly configuring a
| terminal can be complicated.
|
| That's why sixel-tmux page has a step-by-step
| configuration guide, and why I often provide config files
| in other projects like https://github.com/csdvrx/indent-
| rainbow : if needed, check
| https://github.com/csdvrx/indent-
| rainbow/blob/main/config/wi... even if I need to update
| it that should give you a good base to start tweaking
| from.
|
| I strongly encourage you to check your configuration with
| the steps suggest on the sixel-tmux page, or at least the
| minimal set of steps shown in
| http://github.com/csdvrx/sixel-testsuite (which I should
| update to show how font change should work, with sixels
| being resize to be kept in perfect alignment with the
| text, as done in mintty, as several people seem to
| believe it's a sixel limitation)
| rashil2000 wrote:
| Oh, I apologize! I was under the impression that your
| executable would work without the /usr/bin/script
| workaround. My bad! I was aware of the Cygwin's tmux
| quirk, but not the script workaround. Thanks again for
| the detailed help!
| rashil2000 wrote:
| Although there's no mosh-server, some people actually
| ported the mosh-client[1] to Windows using C#. This client
| is currently being used in the popular Fluent Terminal for
| Windows[2].
|
| [1]: https://github.com/jumptrading/mosh-windows-wrappers
|
| [2]: https://github.com/felixse/fluentterminal
| zadjii wrote:
| At one point, I think that was one of my in-parallel goals of
| the Terminal project, but at this point I think it's just
| become a part of my own mental goals for the Terminal. There's
| already so much of the tmux-like stuff that I really liked from
| tmux, that we may as well just go whole-hog on it at this point
| :)
| csdvrx wrote:
| @zadjii, in case it's not clear enough from my praises on how
| promising Windows Terminal Preview is, thanks a lot for all
| the wonderful work you're doing with the Windows Terminal
| team.
|
| At first I was afraid the project would take the easy way out
| and ignore hard features or take shortcuts (ex: SGR1 : bold
| or bright? or both? or none?) but you have shown you are
| willing to do what it takes to properly support applications.
|
| This is not just in line with the reputation of Microsoft
| when it comes to backwards compatibility, but going above and
| beyond to make sure everything works perfectly.
|
| When sixel support is added to WT, it will replace mintty as
| my favorite terminal -- and I'm _very_ picky when it comes to
| terminals.
|
| WT is a wonderful contribution to the open source world, and
| I hope it will inspire similar terminals on Linux (or be
| usable through wine)
|
| Oh, and uh, my apologies if you felt my contribution to the
| sixel thread (PR #448) were out of line. Since your last
| message, I've realized my posts may be off topic, as a
| degraded mode is not what most people may want, even as a
| stopgap measure, so I've stopped posting there.
| dinedal wrote:
| The rant is a much better read and insight into the reason for
| this: https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md
| echelon wrote:
| This is such a good read. I hope this person goes far and gets
| wider support for this. I really like their project and their
| motivation.
|
| > Sorry guys, but I don't want you to hold Linux terminal users
| hostage for your petty concerns over what is the "right" way to
| do something like sixels. [...] It's something that has been
| done successfully for over 30 years.
|
| ...
|
| > Still, you could successfully block sixel support by having
| control over the terminal emulators or the libraries. Ok, but
| now, try to prevent your users from running sixel-tmux!
|
| ...
|
| > Also, you guys like to say that the only voices that matters
| are from those who can code? Hmm, ok for that too. Let's see
| how you like the code I release to show the pointlessness of
| your petty fights, and free your users from your questionable
| decisions.
|
| Also, I wasn't familiar with the term "sixel". They've been
| around since DEC introduced them in the 80's:
| https://en.wikipedia.org/wiki/Sixel
| speeddemon wrote:
| >This is such a good read. I really like their project and
| their motivation.
|
| I can't agree. Like most rants, I found it to be very
| needlessly emotional, lacking in the technical department,
| and motivating towards the wrong goal (trying to fight and
| argue with maintainers, accusing them of negative things like
| "holding users hostage", etc) rather than doing the right
| thing for users (delivering new and useful features in a way
| that isn't broken). I wish open source programmers would make
| less rants and emotionally-driven forks, it's not helpful to
| someone like me who just wants to get something new like
| images in their terminal. The issues in the GNOME/WT bug
| trackers are what actually contain technical information. And
| just from looking at that, it appears there is an open
| development branch for VTE that contains sixel support:
| https://gitlab.gnome.org/GNOME/vte/-/issues/253
|
| So if you use GNOME, I would say just use that and work on
| that, the quality is going to be better than the degraded
| functionality you get from de-rasterizing. In my opinion, it
| would be better from a technical standpoint if the author
| just wanted to work on that, or wanted to work on getting it
| implemented proper in WT. The degraded-image approach used by
| this tmux fork is unusable for the cited use case of getting
| nice graphs in the terminal, and I can't see how it's going
| to make it any easier for those other terminals to solve the
| real technical issues with sixel.
|
| Edit: I also want to respond to this comment in the rant:
|
| >What will happen as Wayland replaces X?
|
| Nothing? XTerm still works. But there is also a Wayland-
| native terminal called "Foot" that supports sixel, if that's
| your thing: https://codeberg.org/dnkl/foot
|
| 2nd edit: To those downvoting, please reply to me instead of
| doing that. If you disagree with me it would be better to
| know why so I could potentially change my view, a downvote
| communicates nothing of value towards changing my mind.
| misnome wrote:
| > I can't agree. Like most rants, I found it to be very
| needlessly emotional, lacking in the technical department,
| and motivating towards the wrong goal
|
| It's titled as a rant, in a file called RANTS.md, and
| unless you've gone out of the way to read it, the rest of
| the immediately available documentation looks to be
| perfectly professional and courteous. I'm not sure what you
| are expecting?
|
| I dislike when this sort of stuff is front-and-center on a
| project but it seems perfectly reasonable to accept that a
| developer might have opinions and feelings that caused them
| to "scratch an itch". People who aren't annoyed with
| existing systems don't in general try to replace or work
| around them, and there's certainly a load of projects I've
| found with disagreeable approaches to contributions or
| governance that I would rather not put my own time into. I
| imagine they feel the same, and appreciate that they
| documented that frustration.
| speeddemon wrote:
| I'm asking for people to stop posting these rants.
| There's nothing wrong with scratching an itch, but the
| rants are just inflammatory and cause drama. I have never
| personally found them to be an adequate documentation of
| governance issues, and it almost always seems to devolve
| into a "he said she said" type of situation. Every time
| I've dug into an issue (this one included) the rant is
| way off-base with what is actually happening, and when I
| push back on it the developer just starts getting hostile
| at me and further fanning the flames. So it's not really
| useful to try and dismiss this by saying "oh it's just
| one piece of documentation you don't have to read it," my
| point is that people are still using these bad attitudes
| to inform themselves when that's a destructive thing to
| do. I mean, come on, someone just posted this in an HN
| comment. If you want to vent to your friends about how
| you think someone is a jerk then just do that, but it
| hurts me when that gets dumped in front of me as someone
| who's just try to comment on these issues and get my
| terminal fixed.
|
| Open source in general has a problem with this, if it's
| left unchecked it leads to toxic behavior very quickly.
| That's my experience anyway. Traditional diplomacy
| doesn't help because some people seem to see open source
| as a "I can do whatever I want" type of thing, which it
| is. It's fine to do whatever you want in your free time
| but once you combine that with an attitude of "I will
| never change my mind or stop ranting" then is when it
| gets destructive and harmful towards someone who is
| trying to build a community and convince other projects
| to collaborate and adopt a shared standard. So if that's
| the goal then the ranting and bad attitudes need to stop.
| (Full disclosure: I'm saying this as someone who used to
| rant quite a lot, and damaged many relationships over it.
| It felt good for me but it made everyone around me become
| distrustful of each other)
|
| If you want to downvote me again then that's fine, but if
| you have something to say then please reply. A downvote
| or an upvote can't mend a broken relationship like a
| strong conversation can.
| csdvrx wrote:
| > I can't agree. Like most rants, I found it to be very
| emotional and lacking in the technical department
|
| It was an accurate assessment of the situation. Read @hpa
| technical analysis if you prefer, but you'll see he and I
| seem to concur: there's nothing technically wrong in
| sixels.
|
| > So if you use GNOME, I would say just use that and work
| on that
|
| The difference between you and I is you still believe what
| they say. I don't. And I question the motives of people
| associated with a project whose official stance is that
| it's acceptable to plan technical hurdles to prevent people
| from using themes:
| https://news.ycombinator.com/item?id=28559716
|
| > In my opinion, it would be better from a technical
| standpoint if the author just wanted to work on that
|
| I have no interest in wasting hours writing then submitting
| code to people who have put into writing the reasons why
| they are playing the clock against sixel support (as if I
| couldn't have read between the lines...), and who have said
| previously they would use their positions to veto the
| inclusion.
|
| By default, I no longer trust them. It's up to them to
| prove they have changed. In the meantime, sixel-tmux will
| exist to push for change, as a pebble in their shoe.
|
| > The degraded-image approach used by this tmux fork is
| unusable for the cited use case of getting nice graphs in
| the terminal, and I can't see how it's going to make it any
| easier for those other terminals to solve the real
| technical issues with sixel
|
| Don't be so focused on one format. There needs to be a foot
| in the door, after which other formats can be added. It's
| just a bootstrapping problem.
|
| Said differently, if tmux can understand sixels and store
| them into some internal representation, it's easy to
| convert from that into other formats as needed (iterm,
| kitty...) meaning others terminals will enjoy the graphical
| formats in pixel perfect quality, as long as they support
| at least one format.
|
| Meanwhile, gnome users will be left to wonder why they are
| left to deal with a derasterized output, and fingers will
| be pointed into the right direction.
|
| Maybe that will encourage the VTE team to do what the users
| want? If not, it will make it easier for alternatives to
| emerge (like "foot" for Wayland that was mentioned here)
|
| What I'm doing is totally a political move, I grant you
| that.
|
| > solve the real technical issues with sixel.
|
| THERE IS NO TECHNICAL ISSUE WITH SIXEL (!!)
|
| Try the nyancat linked below. Look at the FPS. 30 fps in
| the terminal is good enough for most uses.
|
| The only issue with sixel is some people hold personal
| grudges against it.
|
| Sorry, but I don't play ball with them anymore.
| speeddemon wrote:
| Have you read this issue? It goes more into detail about
| the issues with sixel:
| https://gitlab.freedesktop.org/terminal-
| wg/specifications/-/...
|
| If these issues keep coming up, and you keep saying
| "sixel isn't broken" then we have nothing technical to
| discuss and it's going off into emotional rant territory.
| You have to respond to the actual technical concerns. In
| addition to all those things, the restriction to only
| paletted images makes it so I personally won't use it, it
| cannot be used to do any kind of accurate graphics. If
| you wanted to work on a new protocol that wasn't broken,
| I think that would be great too.
|
| Also I think you are making more erroneous and emotional
| arguments when you say these things:
|
| >And I question the motives of people associated with a
| project whose official stance is that it's acceptable to
| plan technical hurdles to prevent people from using
| themes
|
| This is misinformation, GNOME is not preventing people
| from using themes. I can go into more detail if you like.
|
| >I have no interest in wasting hours writing then
| submitting code to people who have put into writing the
| reasons why they are playing the clock against sixel
| support (as if I couldn't have read between the
| lines...), and who have said previously they would use
| their positions to veto the inclusion.
|
| You don't need to submit any code, you could produce a
| fork as you already have done. Then once that's done, you
| could send it to someone else who could get it cleaned up
| for submission, if you were interested. Please don't
| fixate on fighting someone or arguing with one person's
| statements when the actual state of the project
| contradicts that.
|
| >Don't be so focused on one format. There needs to be a
| foot in the door, after which other formats can be added.
| It's just a bootstrapping problem.
|
| This doesn't make sense, the issue here seems to be the
| sixel protocol itself, and getting a foot in the door
| won't help when the format itself is broken. You would
| need to go back to square one in any case to design a new
| protocol. I think it's good to have a project that can
| convert between the different formats, but starting with
| a baseline of a broken format that doesn't work is just
| going to ensure that everything stays broken.
|
| Also, using sixel to display animations seems like an
| extremely bad idea. You'll always get horrible
| performance that way. That to me seems just like it's
| growing towards a really bad and outdated reinvention of
| an X11 or RDP-style protocol. I'd say it's a mistake to
| pursue that.
|
| >Maybe that will encourage the VTE team to do what the
| users want?
|
| I posted a link to it, but VTE already has started adding
| support for Sixel.
| csdvrx wrote:
| First, stop accusing me of being emotional.
|
| Second, tell me why 24 bits colors is insufficient for
| drawing into the terminals?
|
| > starting with a baseline of a broken format that
| doesn't work
|
| Look at that https://github.com/hackerb9/sixvid and that
| https://github.com/libsixel/libsixel and tell me
| precisely what doesn't work, in your own words.
|
| If you can't...
|
| > then we have nothing technical to discuss
|
| ... I think you may be right there!
| speeddemon wrote:
| You're saying you're "reading between the lines", that
| reads to me like an emotional statement, not a technical
| one. Please let's focus on the technical issues at hand
| and what has actually been said, not on what we think
| someone might be saying.
|
| >tell me precisely what doesn't work, in your own words.
|
| I already explained it, I've used sixel in Xterm and Foot
| and I don't like it, the restriction to paletted images
| makes everything look bad. Also, changing the font size
| breaks the images. Also, the protocol is still terrible
| on bandwidth, if you use it to try to transmit 1080p
| video over ssh (as someone is bound to do) then you will
| encounter the same bandwidth issues. Again please read
| this issue if you want to know more about my stance, I
| agree with everything it's saying:
| https://gitlab.freedesktop.org/terminal-
| wg/specifications/-/...
|
| So sixel-tmux is not going to help me, sorry. It may even
| make things worse for me if apps are trying to use it
| when I don't want it. If you want some more suggestions
| on what to do to help, I can give those. But you're also
| welcome to not listen to me if you disagree. Maybe you
| have to accept that I am just not in your target
| audience, but that's no reason to accuse other
| maintainers of trying to hold me hostage.
|
| Edit: I said earlier that I think it would be a good goal
| to support the various image protocols, I would be happy
| to use this if eventually an image protocol was added
| there that wasn't seriously flawed. But the apps and
| terminal emulators will still have to be changed to
| support that, so supporting sixel doesn't really help
| towards that goal at all, and in some ways it impedes it
| because those projects might be expected to maintain that
| as a backwards compatibility option. That's what I meant
| earlier, I think you may be approaching this problem from
| the wrong angle.
| csdvrx wrote:
| > the restriction to paletted images makes everything
| look bad
|
| Not with 16 million colors. That's what 24 bit color mean
| (2^16) also called "truecolor" mode
|
| > Also, changing the font size breaks the images.
|
| Not on mintty. I can change the font size up and down, it
| even resizes the sixels in proportion so the images
| remain aligned to the text in a pixel-perfect way.
|
| It's a terminal problem. You are using bad terminals. I
| grant you that xterm is the least worst option on linux,
| but do yourself a favor and try mintty on Windows.
|
| > Also, the protocol is still terrible on bandwidth
|
| Are you using telnet on remote hosts? Unless you do that,
| with ssh, compression means I can stream video (!!!) just
| like on local hosts (where bandwith is not an issue)
|
| > It may even make things worse for me if apps are trying
| to use it when I don't want it.
|
| In the future, sixel-tmux will intercept sixels live and
| rewrite them into other format, like iTerm or kitty.
|
| How is that making things harder for you?
|
| If you really don't want sixel even if your terminal
| supports them, use the appropriate terminfo and you will
| see nothing.
|
| > seriously flawed
|
| You have yet to tell me the flaws in your own words,
| flaws that are not due to a given terminal.
|
| Try to use sixel to play videos in mintty, with 24 bit
| support so palettes aren't a problem. Then try tweaking
| the font size (why not!), notice how it remains a perfect
| user experience, then we'll talk again.
|
| For now, all I see is FUD.
| speeddemon wrote:
| >Not with 16 million colors. That's what 24 bit color
| mean (2^16) also called "truecolor" mode
|
| >Try to use sixel to play videos in mintty, with 24 bit
| support so palettes aren't a problem.
|
| You are confusing sixel with the iTerm image protocol
| which is different. Sixel is a really old and outdated,
| inefficient protocol that only supports uncompressed
| 6-bit paletted images. It would be best if we could just
| stop talking about sixel altogether, because this is not
| even what you're referring to anymore. I'm actually
| concerned that you're conflating these two, it would also
| best if you could be clear about this in terms of your
| project so it's not confusing as to what your project
| supports. Maybe the name should change from sixel-tmux at
| some point?
|
| SSH compression is not going to be better than the
| image's native compression, you really don't want to rely
| on that to compress your images when we already have
| dozens of other better ways to transmit video.
|
| >Not on mintty. I can change the font size up and down,
| it even resizes the sixels in proportion so the images
| remain aligned to the text in a pixel-perfect way.
|
| I'd love to look into how that's accomplished but I can't
| use mintty because I use a Mac, sorry. I'm also not
| really interested in trying to mess with mingw just to
| get this set up.
|
| This isn't FUD either, you're saying the terminals are
| bad, well, there is no terminal I can use that works
| correctly, I suggested to help out fixing the terminals
| if you know how and you basically said no. So what am I
| supposed to do? Part of making a good protocol is making
| one that is easy for the apps and terminal emulators to
| implement correctly, if that doesn't exist, then like I
| said you have to go back to square one. Adding this
| support to tmux is useful in some cases, but it still
| isn't going to help with getting the terminals to
| implement this right.
|
| >In the future, sixel-tmux will intercept sixels live and
| rewrite them into other format, like iTerm or kitty.
|
| This is a good idea, please do this instead of trying to
| get other terminals to adopt Sixel when they are just
| going to have to replace it down the line anyway.
| csdvrx wrote:
| > You are confusing sixel with the iTerm image protocol
| which is different.
|
| No I'm not.
|
| > Sixel is a really old and outdated protocol that only
| supports 6-bit paletted images.
|
| No it doesn't.
|
| sixels can be 16 million colors, that's precisely what
| the snake.six outputs tests: if you can't see the precise
| degradation of the snake skin greens and yellows, your
| terminal is broken.
|
| With so many bad terminals, it's no wonder that a lot of
| people have such a bad opinion about sixels!
|
| > It would be best if we could just stop talking about
| sixel altogether, because this is not even what you're
| referring to anymore. I'm actually concerned that you're
| conflating these two
|
| Actually, with what you said, I think you're the confused
| one here. When you could not express in your own words
| which practical limitations were imposed by sixels, I was
| 99% sure.
|
| Now I'm 100% sure you have no idea of what you are
| talking about. Sorry if it's blunt, but take the time to
| run the tests I've suggested to correct your
| misconceptions about sixels.
|
| Maybe you'll end up loving the format once you see what
| it's really capable of?
|
| > I'd love to look into how that's accomplished but I
| can't use mintty because I use a Mac, sorry. I'm also not
| really interested in trying to mess with mingw just to
| get this set up.
|
| Intel macs can run Windows natively. You've also got your
| pick of emulators, from parallels to vmware, if you roll
| that way.
|
| So install Windows one way or another, go to msys2.org,
| download the latest release, click on install. No messing
| required, mintty is here by default.
|
| You can then use pacman if you want more, which BTW is
| far better than most of the package managers available on
| Mac: simply follow the pacman update steps clearly
| explained with many screenshots on the first page.
|
| Then you'll have an up-to-date msys2 install, with most
| of the linux tools you want running natively (no WSL
| involved) or just a `pacman -S` away.
|
| >> In the future, sixel-tmux will intercept sixels live
| and rewrite them into other format, like iTerm or kitty.
|
| > This is a good idea, please do this instead of trying
| to get other terminals to adopt Sixel when they are just
| going to have to replace it down the line anyway.
|
| What you've written makes about as much sense as saying a
| drawing program should stop trying to support BMP format
| since it will have to be replaced down the line by JPG or
| PNG.
|
| gimp, paint and others support many formats. Nobody is
| complaining. People just click on open. They don't care
| about the underlying formats.
| speeddemon wrote:
| https://vt100.net/docs/vt3xx-gp/chapter14.html#T14-1
|
| Am I reading this incorrectly? It seems I was wrong, it
| supports 8-bit color, not 6-bit color. But that's still
| terrible, and every Sixel implementation I've ever used
| has spit out dithered images. The only terminal that is
| able to display full color images for me is iTerm, using
| the iTerm escape sequences, which are different escape
| sequences from sixel. So again, please help out with
| fixing this for me if you know how. Because so far you
| have not adequately explained what is going on here, or
| corrected any misconceptions, or helped to fix anything
| that is wrong with these terminals. And even the various
| libsixel examples seems to show dithering:
| https://github.com/saitoha/libsixel
|
| If I'm confused then you could be in a great position to
| help me out, so please explain what apparently myself and
| the libsixel authors are both doing wrong. Then maybe at
| some point in the future I could help you out and return
| the favor.
|
| And there are also other problems with the iterm escape
| sequences that I suspect will prevent you from correctly
| implementing them in tmux (see here:
| https://gitlab.com/gnachman/iterm2/-/issues/3898). So all
| paths point towards needing to make some new protocol for
| this. You may be in the best position to do that too.
|
| >Intel macs can run Windows natively. You've also got
| your pick of emulators, from parallels to vmware, if you
| roll that way.
|
| I'm not going to dual boot Windows or use a VM just to
| use a terminal emulator for a couple minutes, sorry. If
| you could just explain what that terminal does that's
| special so that it could be implemented in other
| terminals, or show a video, that would help.
|
| >What you've written makes about as much sense as saying
| a drawing program should stop trying to support BMP
| format since it will have to be replaced down the line by
| JPG or PNG. gimp, paint and others support many formats.
| Nobody is complaining. People just click on open. They
| don't care about the underlying formats.
|
| If GIMP was attempting to pressure other projects to
| output BMP files then yes, that would be a problem. I
| suspect other projects wouldn't go for that just because
| they asked.
| csdvrx wrote:
| > Am I reading this incorrectly?
|
| Yes
|
| > It seems I was wrong, it supports 8-bit color, not
| 6-bit color.
|
| Good.
|
| A positive first step is knowing when to admit error.
|
| > But that's still terrible, and every Sixel
| implementation I've ever used has spit out dithered
| images
|
| OMG, I spoke too fast, there you go again!
|
| I've given you a step-by-step guide to try the best
| terminal there is.
|
| > So again, please help out with fixing this for me if
| you know how.
|
| I HAVE TOLD YOU AT LEAST 4 TIMES: YOU NEED TO USE A STATE
| OF THE ART TERMINAL TO FIRST CORRECT YOUR MISCONCEPTIONS.
|
| Then if you are speaking in good faith, we will talk
| again.
|
| > Because so far you have not adequately explained what
| is going on here, or corrected any misconceptions, or
| helped to fix anything
|
| I'm at a loss. I can't hold your hand while you install
| msys2 so you realize yourself you were wrong, just like
| you did with the 24 bit colors which you wrongly assumed
| to not be supported by sixels.
|
| Let's try a Bayesian approach: considering you have been
| proved wrong, you should update your priors and consider
| the likelihood of being wrong again is greater than me
| being wrong, since I have 1) quite an experience with
| sixels 2) so far I've been proven right.
|
| > I suspect will prevent you from correctly implementing
| them in tmux (see here:
| https://gitlab.com/gnachman/iterm2/-/issues/3898)
|
| You are pointing me to a 6 years old bug report about
| tmux eating sequences important to display sixels, which
| funny enough is the original concept behind sixel-tmux:
| click on my profile and you will notice "Show HN: Sixel-
| tmux, display graphics because it does not eat escape
| sequences" by csdvrx on Nov 27, 2019
|
| I agree it was a serious issue, enough to motivate me. I
| didn't know it was also affecting iterm. At least I
| learned something too from this exchange, thanks a lot!
|
| > So all paths point towards needing to make some new
| protocol for this. You may be in the best position to do
| that too.
|
| All path point toward you mixing up terminal issues and
| sixel issues, not using the right tool, refusing to even
| try to use the right tool.
|
| But yes, a few of us are in a position to push for better
| standards. I think @christianparpar and @hpa have the
| deepest understanding of the alternative standards.
| Eventually a few standard may emerge... or not. It
| doesn't matter. BMP, GIF, PNG and JPG can all coexist,
| each have their pros and cons. There's no need to make a
| choice when all apps support loading and saving in the
| user favorites formats.
|
| > I'm not going to dual boot Windows or use a VM just to
| use a terminal emulator for a couple minutes, sorry.
|
| Then I'm not going to try to explain you what you are
| understanding in a wrong way, as only seeing how mintty
| handle sixels WITH YOUR OWN EYES may correct your
| misconceptions at this point.
|
| > If you could just explain what that terminal does
| that's special so that it could be implemented in other
| terminals, or show a video, that would help.
|
| Click on the url and you'll see a few demos, including
| the snake.six displayed in a wonderful example of 24 bit
| "truecolor" support.
|
| Your request to add a video showing how mintty handle
| font changes seems resonable. It will make a nice
| addition to sixel-testsuite.
|
| > If GIMP was attempting to pressure other projects to
| output BMP files then yes, that would be a problem
|
| If other projects did not even support BMP, but only knew
| about drawing ASCII art with a 8 colors palette, yes,
| refusing to implement BMP in 24 bit mode as a first step,
| while spending 6 years debating the best way to achieve
| the perfect format that will have absolutely no drawback
| (chasing a wild goose) would indeed be a problem...
| noergl wrote:
| Imho there is some misconseption here, how the sixel
| protocol works for the colors part. It is not about any
| bit-depth of an image, as it is paletted. But other than
| most standard paletted formats, it can redefine its
| colors on-the-fly, which basically makes it supporting an
| infinite amount colors (it is still limited to 1013
| colors in RGB space).
|
| Now the actually tricky parts: The spec states (DEC STD
| 070), that the palette should be of size 256 at least on
| decoder side, and an encoder should not create more than
| 256 colors, and any higher palette index gets mapped back
| (not specced out, but mostly done with modulo). Older
| devices (old DEC printers or VTs) were even more limited
| in palette regards, from monochrome like VT240 to 16
| colors on a VT340 for screen output. Thats what xterm
| does with `-ti 340` and it is totally right about it - it
| emulates what a VT340 was capable to do. What mlterm
| started to do (and others followed) - well it did not
| care for strict VT340 emulation, and increased the
| palette to 256 colors. Furthermore it applied "printer-
| behavior" (note - sixel was developed as printer
| protocol) deviating from DECs VT behavior by immediately
| applying colors to pixels. While DEC's sixel capable VTs
| always were bound to the fixed palette. That terminal vs
| printer behavior distinction is important, as it opens
| sixel to actually use more colors than the palette has
| room for by redefining color slots on the fly.
|
| Hope this helps to get some details straight.
| traverseda wrote:
| https://saitoha.github.io/libsixel/
|
| Looks to me like the limited pallete is mostly as XTerm
| limitation, but a limitation of the protocol.
| speeddemon wrote:
| From reading the protocol "spec" I do not see how it
| could be used to transmit 32 bit color (or higher). The
| spec describes 8 bit indices into a palette. I have seen
| no sixel tools that are able to output 32 bit color, or
| any sixel terminals that can display 32 bit color. But I
| could be misreading it. I haven't dug through all the
| code so if someone could show how this could be done,
| then we could start to change those sixel implementations
| to do the right thing.
| csdvrx wrote:
| > I do not see how it could be used to transmit 32 bit
| color (or higher)
|
| You are pushing the goalpost. I was talking about 24 bit
| color (2^24= 16 millions).
|
| Now you are saying the lack of 32 bit color support is an
| issue?
|
| Maybe let's start with 24 bit color, which is far more
| than what the human eye can discern anyway (about 10
| million) even if we'd then have to talk about color
| spaces, and how 32 bit may be better for some specific
| applications)
| seg_lol wrote:
| Thank you!
| cyberge99 wrote:
| For macos users using iTerm2, installing the integration provides
| 'imgcat' and 'imgls'. Not sure about tmux support though.
| csdvrx wrote:
| I have plans to add support for iTerm format, but I'm not a Mac
| user, while of the work should not be on the derasterize part
| (image -> unicode text: easy), but on the passthrough part
| (when to abandon the image).
|
| If you are a Mac user, could you please consider writing a
| patch? The ability to dogfood it means whatever you write will
| still be better than whatever I may come up with.
| saladuh wrote:
| OP, your rants are pretty subjective and imo come from a place of
| windows fanboy-ism (before someone reports this comment for flame
| baiting, go read both of OP's rants in the repo, they're far
| worse).
|
| I came to Linux last year, and I've been on it 100% no windows
| during this entire period.
|
| I'm using Sway (Wayland), a DE (well, really just a window
| manager) you cannot replicate in the windows graphical
| environment, and I'd never go back. Everything is so smooth, and
| of course you may say that it's "because vsync is used in Sway
| and vsync = bad blah blah", but I've never agreed with that and a
| good implementation of vsync with minimal latency increases is
| worth it, especially paired with freesync/adaptive sync (which
| works on the desktop just as it does in Windows).
|
| Fyi, before my Linux days, I was a very competitive gamer, and
| absolute windows power user. I went out of my way to get every
| last bit of performance and latency reduction possible (just so
| you know where I'm coming from).
|
| My terminal emulator is Foot, a wayland native terminal with a
| focus on TUI performance, especially in TUI editors like (neo)vim
| (my editor of choice). It has amazing Sixel support with a
| developer who goes out of his way to fix even the smallest
| imperfections with the implementation. Foot has features I really
| love, like link following by keyboard shortcuts, great font
| fallback customisation, and no bloat (a feature in my book)
|
| My multi-resolution setup is not impacted by Linux because Sway,
| and Wayland ecosystem in general, handles multi resolution
| tremendously, and supports integer and fractional scaling per
| display. Multi display freesync/adaptive-sync (and gsync whenever
| Nvidia starts playing ball) works great too, just as it does on
| windows.
|
| The majority of stuff you complain about is due to crusty old X11
| (whether you're stuck on X because of nvidia or not, it's not a
| fair argument). Or because you think the way Windows does
| something is better than the way Linux does that thing (even
| though in most cases I think the opposite, clearly a subjective
| thing).
|
| Oh, and yea I think Windows sucks and Linux does <insert> better.
| But I'm saying that as a zoomer, not a "geek millennial" (as you
| said in your rant) :)
| ayushnix wrote:
| I'll probably regret writing this but if you read the entire
| rant, the author had been trying get sixel support into VTE
| based terminals (GNOME terminal and family) but he was blocked,
| which isn't really surprising considering the "my way or the
| highway" approach of GNOME devs towards anything that they
| make. The recent theming fiasco is a good example for this.
|
| He also tried getting sixel support in tmux but was rejected
| again. All he did was make a hard fork to get the feature that
| he wanted. That's it. The end. There are some things that
| Windows does better and some things that Linux does better.
| Generalizing your anecdotal experience and implying that one is
| entirely "better" than the other is what fundamentalism and
| fanaticism looks like.
| easygenes wrote:
| Yeah, I think OP wrote must of what they did in genuine
| frustation. Saladuh's response probably comes mostly from
| having read this paragraph from OP's rant: "This is why I
| released sixel-tmux. That's also why I use Windows besides
| the wonderful mintty being the number 1 choice for terminal
| afficionados, it gives more options in general: I like that
| because I don't like depending on people who seem stuck in a
| desire to be lord-of-the-flies. Unfortunately, there seem to
| be quite a few in the free software world..."
|
| Also they go on from there about how they want to encourage
| Linux users to jump over to Windows. Again, I think this is
| just frustration with their perception that there are too
| many control freaks in the opensource world acting as
| gatekeepers for important feature availabilities (the core of
| their rant is just that they really wish they could have done
| graphical plots in their default terminal when they were in
| school years ago).
|
| To my reading, it sounds like someone who wanted to support
| free software who jumped over to Windows in disgust, not
| really a "Windows fanboy."
| easygenes wrote:
| The strangest thing to me though is that the OP finished
| this work last year and sat on it until very recently. They
| explain it as "I wrote this for a client and didn't feel
| like sharing it." That attitude seems a bit in contrast to
| the purported motivation to, "Make it so people don't
| suffer like I did in school."
|
| So I guess in a way OP is (sort of) seeing the light on
| free software here too. Don't like it? Fork it!
| ayushnix wrote:
| Hard forks rarely get traction and are almost always lost
| in obscurity, unless the original project itself is
| abandoned. tmux isn't abandoned so I doubt this fork will
| end up being used by more than a handful of people.
|
| EDIT: Yup, as suspected, the author doesn't intend to
| keep his fork updated with upstream and I don't blame him
| for that. This essentially makes this fork a proof of
| concept, nothing more. Unless it gets merged in tmux
| itself, people might as well forget that this fork
| exists.
|
| https://github.com/csdvrx/sixel-tmux/pull/1
| csdvrx wrote:
| Thanks for being understanding.
|
| To be honest, Windows fangirl? guilty as charged!
|
| But I try to keep my personal opinions separate, which is
| why my rants are on a separate page.
|
| Still, you nailed it: sixel-tmux was made to try to help
| correct the direction that has been taken, with 6 years
| wasted.
|
| I believe it's unfair that Linux users have fewer options
| than us Windows users, due to some people thinking sixel
| is "uncool".
|
| Desperate times call for desperate measures. Publishing
| this fork was a last resort move, for the exact reasons
| you stated: forks are often lost in obscurity.
|
| However, the situation seems to be changing: check the
| discussion in: https://github.com/csdvrx/sixel-
| tmux/pull/1 and you'll see there may be some light at the
| end of the tunnel!
|
| A compile time flag is not ideal, but if at least
| derasterize can be added by default, so that every tmux
| user can have some kind of graphics in the terminal, even
| if said graphics are not sixels but derasterized, that
| would be "good enough" to me.
| ayushnix wrote:
| > Thanks for being understanding.
|
| No problem. I know maintaining forks isn't an ideal thing
| to do and support should ideally land upstream.
|
| > I believe it's unfair that Linux users have fewer
| options than us Windows users, due to some people
| thinking sixel is "uncool".
|
| I think the README page of termite pretty much sums up
| why getting involved in VTE, or any GNOME project for
| that matter, is a bad decision.
|
| https://github.com/thestinger/termite/blob/master/README.
| rst...
|
| I'm just a random spectator but perhaps your efforts
| might've been better spent on an independent terminal
| project (like Alacritty, for example) rather than trying
| to get features merged upstream in a GNOME project.
|
| > However, the situation seems to be changing: check the
| discussion in: https://github.com/csdvrx/sixel-
| tmux/pull/1 and you'll see there may be some light at the
| end of the tunnel!
|
| Yeah, I read the entire conversation and if sixel support
| lands in tmux upstream, it would indeed be good news.
| csdvrx wrote:
| > I think the README page of termite pretty much sums up
| why getting involved in VTE, or any GNOME project for
| that matter, is a bad decision. > > https://github.com/th
| estinger/termite/blob/master/README.rst...
|
| Wow, this confirms a lot of my impressions:
|
| >> In 2012, we submitted a tiny patch exposing the APIs
| needed for the keyboard text selection, hints mode and
| other features. Despite support from multiple other
| projects, the patch was rejected. It's now almost a
| decade later and no progress has been made. There is no
| implementation of these kinds of features in VTE and it's
| unlikely they'll be provided either internally or as
| flexible APIs. This is the tip of the iceberg when it
| comes to their hostility towards other projects using VTE
| as a library. GTK and most of the GNOME project are much
| of the same. Avoid them and don't make the mistake of
| thinking their libraries are meant for others to use.
|
| This is exactly why sixel-tmux exists as a separate
| entity!
|
| > Yeah, I read the entire conversation and if sixel
| support lands in tmux upstream, it would indeed be good
| news.
|
| I'll keep my fingers crossed, but right now, there seems
| to be a lot of good will. I will do everything I can.
| ayushnix wrote:
| Yep, that's all it was.
|
| I have a few things that I can't stand and I have no
| problem ditching something that doesn't offer me what I
| want. For example, I ditched Kitty because it doesn't let
| me disable italic variants of monospace fonts. In a
| hypothetical scenario, if tmux/screen didn't exist and
| Kitty was the one terminal which had these features, I
| would be frustrated as well if the dev didn't budge from
| his position of not letting users disable italic fonts.
| Fortunately, tmux exists and Alacritty lets me disable
| italics.
|
| It's pretty naive and immature to get married to the tools
| you're using. Unfortunately, you see this a lot in the FOSS
| world.
| tlamponi wrote:
| I read the rant and did not see the windows-fanboyism you
| suggest, on the contrary, they wish that a big chunk of the
| terminals used in Linux get support for a feature, and they do
| not just complain, but they actually do something for making
| things better. So I'm not sure your rant is warranted nor makes
| it much sense in this context, or is this some copy-pasta I
| failed to recognize?
| KaiserPro wrote:
| Ooo I didn't even know that Sixel was a thing.
|
| This looks fun
| flohofwoe wrote:
| I tinkered a bit with sixel support for my "C64 emulator in the
| terminal" (https://github.com/floooh/docker-c64), but
| unfortunately it's way too slow to get anywhere near 'realtime'
| output (30fps or better).
|
| Here's the (abandondend) sixel-version source code, only with
| two colors, more color planes would drastically reduce the
| performance.
|
| https://github.com/floooh/chips-test/blob/master/examples/as...
|
| I really wish there was a decent pixel-framebuffer standard for
| terminals (with at least the same performance as ncurses). This
| would allow a lot of fun "terminal applications" (e.g.
| everything that used to run in VGA Mode 13h).
| csdvrx wrote:
| > unfortunately it's way too slow to get anywhere near
| 'realtime' output (30fps or better).
|
| That's not due to sixels. Check out the sixel nyan cat:
| https://github.com/hackerb9/sixvid
|
| Look at the FPS indicator in the bottom. It was pointed to me
| in https://github.com/microsoft/Terminal/issues/448#issuecomm
| en...
|
| The issue may be in your code.
|
| I think I have similar performance issues, as the glyph
| selection process could be more optimized.
|
| Derasterized is mostly Jart work (who is best known here for
| her work on Cosmopolitan), we were mostly interested in
| quality.
|
| Reducing the set of glyph to something that could benefit
| from optimizations could help.
|
| > I really wish there was a decent pixel-framebuffer standard
| for terminals (with at least the same performance as ncurses)
|
| Sixel performance is quite decent: personally, I can play
| videos in my terminal.
|
| Try MPV on mintty: https://github.com/mpv-
| player/mpv/issues/2183
|
| I have also played with a X server rendering over sixel, no
| performance issue: https://github.com/saitoha/xserver-SIXEL
|
| When sixel support is added to Windows Terminal, I may update
| it, because it would be fun to have one tab to run stuff!
| flohofwoe wrote:
| Wow interesting, thanks for the links! I still suspect it's
| a performance issue in the terminal(s) I tested (mainly
| iTerm2 on Mac, and probably Ubuntu's vanilla terminal),
| because it would take a lot of effort to make encoding a
| 320x200 framebuffer to sixels slow ;)
|
| I should definitely have another look though, it's good to
| know that it _is_ possible to get decent performance out of
| sixels.
| csdvrx wrote:
| > Wow interesting, thanks for the links!
|
| Indeed! It's nice to see what's possible!
|
| As for video playback, while it may not be realistic with
| the current sixel-tmux due to the size of the search
| space, it may be possible once the new 1FBxx block https:
| //en.wikipedia.org/wiki/Symbols_for_Legacy_Computing is
| integrated into derasterize and the suggested fonts:
| restricting ourselves to the 1FB0x-1FB3x subset would
| only require adjudicating about 64 characters.
|
| Some very basic programming tricks (a bloom filter after
| binarization of the input, memoizing...) may be
| sufficient to derasterize sixel videos in real time, even
| on an average system.
|
| > I still suspect it's a performance issue in the
| terminal(s) I tested
|
| If you don't use Windows, try xterm and mlterm. For
| xterm, I maintain a set of config files giving you a
| decent out-of-the box experience, cutexterm
|
| > I should definitely have another look though, it's good
| to know that it is possible to get decent performance out
| of sixels.
|
| Indeed :) It's a format that has been unfairly dismissed.
| It's old, but we have great tools like libsixel to do
| anything we want with it in this millenium.
|
| Speaking of libsixel, also check
| https://github.com/libsixel/libsixel a recent fork that's
| open to PR
| Lio wrote:
| This is really interesting (to me anyway).
|
| I normally just default to using Gnome Terminal on Linux, which
| sadly doesn't support Sixels, so I'll definitely give this a go.
|
| Looking around I've just found Foot, which looks like it does
| support Sixel on Wayland[1].
|
| So that might be a more permanent way forward.
|
| 1. https://codeberg.org/dnkl/foot
| easygenes wrote:
| Any insight into how this one compares to Alacritty and Kitty?
| ayushnix wrote:
| > Any insight into how this one compares to Alacritty and
| Kitty?
|
| In terms of customization and configuration, I'd say foot
| falls between Alacritty and Kitty with Kitty being the most
| customizable and configurable while Alacritty being the
| least.
|
| One of the things I really like about Alacritty and foot is
| that they don't enforce italic and bold monospace variants
| while Kitty does. I despise italic variants of monospace
| fonts. Most monospace fonts don't even have proper italic
| variants. They're just slanted.
|
| I tried using foot a few days ago but went back to Alacritty
| because of this issue.
|
| https://codeberg.org/dnkl/foot/issues/628
|
| I think I might move back to foot though because it felt a
| bit faster (lesser latency) and for some reason, text on
| Alacritty is sometimes blurry for me.
| trapnii wrote:
| Hey; what do you mean by "force"? I mean, to me this reads
| like you don't want to see italic nor bold font in the
| terminal (due to lag of monospace support in that regard
| maybe).
|
| But I think having the possibility of italic, bold,
| bold+italic in the TE is a very good thing. And if you do
| not want that I think Kitty allows you to just use another
| font then; please correct me here, but I think that is
| configurable. Bold text in the TE world is yet another
| heated discussion. Some people like it bold, some people
| like the color to be intensified instead when using `SGR 1`
| (which is responsible for making font intensified/bold).
| ayushnix wrote:
| > And if you do not want that I think Kitty allows you to
| just use another font then
|
| Do you really believe that's reasonable? That I should
| stop using my favorite monospace fonts just because a
| terminal emulator doesn't let me disable italic variants
| of that font when other terminal emulators like Alacritty
| and foot do?
|
| I don't think that's reasonable and so I stopped using
| Kitty. And no, I'm not gonna resort to fontconfig hacks
| or manually delete the italic otf/ttf files. I'd rather
| use a terminal that gives me choice rather than imposes
| it.
| csdvrx wrote:
| > Some people like it bold, some people like the color to
| be intensified instead when using `SGR 1` (which is
| responsible for making font intensified/bold).
|
| Indeed, and the right solution is a config options, just
| as was done in Windows Terminal, since nobody is wrong:
| it's just a matter of preferences!
|
| The right technical way of handling preferences is
| offering more choices to the users, with some sane
| default that will satisfy most users.
|
| Personally, I love italics (I use vim and I want comments
| shown in italics, and I make an heavy use of
| bold+italics, cf https://github.com/csdvrx/indent-
| rainbow/blob/main/after/syn... ) but I would not want to
| force this option to people who don't want italics, for
| their own reasons that are none of my business (actually,
| if they reasons are good enough, it may cause me to
| change the default choices, but I would never remove the
| user freedom to make such choices in the first place)
|
| IMHO that's the key difference between
| MacOS/iOS/Gnome/new school linux on one side (fewer
| freedoms) and Windows/KDE/old school Linux (more
| freedoms)
| Lio wrote:
| I've not installed Foot myself yet (on the todo list today)
| but I don't think either Alacritty or Kitty support the Sixel
| interface itself.
|
| Kitty supports images via a custom API. There's loads of
| really cool plugins for it but what's interesting about Sixel
| support is that it's a standard, even if it's primitive.
|
| I'm not sure that Alacitty can support images or, at least, I
| couldn't see that reported anywhere (it's been a while since
| I ran it myself).
|
| In terms of performance Foot seems to compare well to
| both[1].
|
| 1. https://codeberg.org/dnkl/foot/src/branch/master/doc/bench
| ma...
| ayushnix wrote:
| You might wanna consider avoiding all VTE based terminals
| (includes GNOME termina) on Linux because VTE development is
| spearheaded by GNOME developers. They're almost always guided
| by their "every preference has a cost" philosophy so don't
| expect any decent changes happening to VTE.
|
| Here's another explanation why VTE based terminals are best
| avoided.
|
| https://github.com/thestinger/termite
|
| Here's a complete list.
|
| https://wiki.archlinux.org/title/List_of_applications#VTE-ba...
| speeddemon wrote:
| That explanation isn't convincing to me, it's getting more
| into emotional territory (they are hostile because they
| didn't accept our patch) and away from technical territory
| (here are reasons why our patch wasn't accepted).
|
| I think VTE is fine if you don't mind development happening
| at a glacial pace...
| kzrdude wrote:
| Sixes support exists upstream, but it seems nothing builds
| using it by default.
|
| https://gitlab.gnome.org/GNOME/vte/-/issues/253
| ayushnix wrote:
| Because sixel support isn't present in any released version
| and only present in git?
|
| https://gitlab.gnome.org/GNOME/vte/-/issues/253#note_1049040
| kzrdude wrote:
| It seems like it will be part of 0.68 then (next stable
| version) according to the milestone on the issue.
| marginalia_nu wrote:
| The world is finally catching up with the capabilities of
| TempleOS.
| ganzuul wrote:
| This is lovely. The author recommended XTerm as one of the best,
| so I would like to suggest trying Kitty for size for graphics.
| saladuh wrote:
| The issue with Kitty is that its graphics protocol is not
| widespread yet, so some of the CLI/terminal programs OP uses
| that can do graphics output may only support sixel. But yea,
| personally looking forward to Foot terminal implementing one of
| the fancier graphics protocols, even if it feels more like a
| toy at the moment (until they are used more). But seriously
| running the notcurses[0] graphics test with a terminal
| supporting the kitty graphics protocol is _sex_ , just like the
| program itself says.
|
| [0] https://github.com/dankamongmen/notcurses
| csdvrx wrote:
| > it feels more like a toy at the moment
|
| It's not! Gnuplot in the terminal open many new use cases,
| such as examining data on remote hosts with scripts without
| even bothering to scp the data first.
|
| Also, Notebooks in the terminal is wonderful!
|
| Check https://github.com/koppa/matplotlib-sixel
|
| As for kitty format, adding support in sixel-tmux is planned,
| but you are welcome to write a patch if you want it sooner!
|
| Imagine sixel-tmux as some middleware, because it is totally
| possible to intercept sixel sequences and rewrite them on the
| fly into something more palatable to kitty or iTerm.
|
| This way, even if gnuplot doesn't support kitty, you could
| still view the results. If it's done well enough, you may not
| even perceive the difference!
|
| That's the direction I want to follow, so that users can take
| any software and play with it on their terminal regardless of
| the underlying format.
| kzrdude wrote:
| A matplotlib backend isn't even needed, just a cool piece
| of info, it's possible to extend ipython and/or jupyter
| console to display pngs and svgs with sixels (and/or kitty
| graphics, dynamically). I have code lying around for this.
| csdvrx wrote:
| Wonderful! Thanks for the info!
|
| I have to check the current state of rstudio/ipython
| console support with sixels: doing everything from the
| terminal is a luxury I want in 2021, especially now that
| hidpi/4k screens are becoming mainstream :)
|
| Last time I tried in uni on a "new" Thinkpad R52 (well,
| new for me as it wall already over 10 years old, but it
| had such a glorious 1400x1050 display!) quite a few
| things were missing.
| kzrdude wrote:
| Thank you yourself for working on sixels and other things
| for image support in terminals. I've seen your work
| before and it's quite inspiring. :)
| swiley wrote:
| Didn't Kitty add opt-out telemetry recently? Either way Xterm
| works very well.
| epicide wrote:
| I wasn't aware of this, but it appears to just be update
| checking with no user data transmitted [0]. I would love any
| other information if there is more to it.
|
| [0]: https://github.com/kovidgoyal/kitty/issues/3802
| seg_lol wrote:
| Your rant and the issues around keeping an ecosystem pinned to a
| mess of incompatible tech reminds me of the time that mpng
| support was pulled/not merged into Firefox because it added too
| size of the binary.
|
| Which was then obviated by the first download of an animated gif.
| Petabytes in bandwidth and disk storage wasted because FF decided
| saving a couple hundred K on the png animation code.
|
| By not supporting sixels, it forces people to use a whole browser
| to show images. Graphics support in the terminal is more than
| just QoL for the users, it is also a power savings and a hardware
| lifetime issue.
|
| You are fighting the good fight.
| csdvrx wrote:
| > Petabytes in bandwidth and disk storage wasted because FF
| decided saving a couple hundred K on the png animation code
|
| Indeed, penny wise but pound foolish... and I guess they were
| proud of themselves!
|
| > You are fighting the good fight.
|
| Thanks, hopefully due to kicking the ant nest with my rants and
| now sixel-tmux, VTE will be forced to deliver something,
| anything really, even if it may be 6 years too late and not
| enabled by default (!!)
|
| At least Linux distributions would have the possibility to
| compile it in?
|
| But at this point, even that I can't believe. I think they will
| weasel out at the last minute with some half-baked more or less
| plausible excuse, like your example about firefox code
| increasing by a few kb.
|
| My hopes for gnome are extremely low, so "I'll believe it when
| I can see it" and not before, say when it's shipping in Ubuntu.
| chaganated wrote:
| Sixel is a terrible encoding. Most of the newer terminals have
| escape sequences for sending base64 encoded png/gif/jpg--for
| higher quality output & lower bandwidth.
| csdvrx wrote:
| > Sixel is a terrible encoding
|
| This is not based on technical facts, but bias against an old
| format.
|
| > png/gif/jpg--for higher quality output & lower bandwidth
|
| For bandwidth, my ssh stream is compressed.
|
| For quality, I can't see difference in a 24 bit bitmap when
| comparing with a png or jpg, unless I compress them too much,
| in which case the compression artifacts start playing AGAINST
| the formats you recommend.
| chaganated wrote:
| it is self-evident to anyone who knows how sixel works. gif
| is no prize--yet still manages to be a more efficient
| encoding than sixel.
| leotaku wrote:
| This is a really cool project. It's unfortunate to see the author
| being this obviously frustrated by having Sixel-related
| contributions be rejected time and time again. However it seems
| like the main Tmux maintainer has shown up on the issue tracker
| about being open to including the changes upstream, maybe that
| will improve their faith in the open-source community.
___________________________________________________________________
(page generated 2021-10-05 23:02 UTC)