[speeddemon]

>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]

> 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]

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]

> 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.

[seg_lol]

Thank you!

[speeddemon]

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.