refuting https://github.com/natpen/awesome-wayland/issues/101 about awesome-wayland HOT 9 CLOSED

Hi 👋 I've just finished reading through both this and the other thread. First of all, thank you for the thorough and thoughtful discussion. It's obvious that the discussion is getting a bit "frayed around the edges" in spite of the fact that many good points are being made all around. I think the fraying around the edges is because it touches on a fundamental challenge of maintaining a list like this - it's intended to be useful and helpful to people, but it's hard to objectively define and quantify "useful" and "helpful". I've personally grappled with this over the years, and often end up just trying to make reasonable inclusion/exclusion calls, rather than put a ton of effort towards codifying the criteria. Sorry you all had to get pulled into that dilemma with me this time! And @wez sorry you couldn't comment on the other issue - I'll double check commenting permissions right after I finish this comment.

Questions I'm thinking through...

Does Wezterm support Wayland? I think the answer is yes - it says so in the official docs, and there is a large body of work in the code that appears to have gone into Wayland support. I realize there's a quote floating around here of @wez saying he personally recommends not using Wayland, but it's fine to have a personal stance and advice at odds with the Repo's stance.

Does Wezterm "work" for a reasonable enough amount of users? This is really hard to answer, even for @wez I'm guessing. (WARNING: wild hand-wavy math incoming! :) It has over 10k stars, so it's a popular project and I'm guessing thousands of users. Looking at issues labelled wayland I definitely see some "it doesn't even start" kinds of ones, but just comparing the number of them to the number of Wayland users I'm speculating exist, I am guessing that severity of issue is affecting a minority of users (though it does look like it has an uphill battle due to the SCTK upgrade that isn't able to be worked on).

Possible solutions...

1. We could remove Wezterm from this list entirely. That feels... not good to me, and unfair to @wez and team, given the above answers.

2. We could put a warning/disclaimer next to Wezterm on this list. That could work, but isn't really an approach I want or precedent I want to set for the sake of maintaining this list.

3. Lastly, here's my idea, taking a step back from Wezterm specifically. Looking at the two other GPU-accelerated ones on the list, I see some similar issues (ref: alacritty issues & kitty issues). I could add a somewhat more general blurb at the top of the Terminal Emulators section that notes that GPU-accelerated terminals are often more bleeding edge or ambitious endeavors, so take care when going down that route and be ready to potentially troubleshoot your way through getting things working.

Thank you again for all the discussion so far! Please feel free to let me know it you're opposed to solution (3) or have other ideas. I'll think through this some more today and let it percolate, to see if any other good ideas come to mind.

from awesome-wayland.

There are no outstanding Wayland issues in kitty and haven't been for a
long time. And not a single report of it not starting.
The ONLY Wayland specific issue it has is CSD on GNOME.

There is nothing about GPU based terminal emulators that makes them
Wayland antagonistic, and it is pretty absurd to label a whole category
of software as not ready for Wayland because of one example of it.

Not to mention completely unfair to those of us who have sunk countless
hours of our time into supporting the ongoing trainwreck that is
Wayland. If you want to maintain a list of software that works on
Wayland, I suggest putting in some actual work to verify and curate that
list or maybe stick a big disclaimer on top of the entire list that
states you have no idea how well or if any of the software currently
works in Wayland.

from awesome-wayland.

I'm rolling around closing tabs and just saw this.

For some reason I'm blocked from commenting on that issue directly?

That's a bit unfair you're being directly quoted there. FWIW, it wasn't me!

Wayland support in wezterm does work,

I mean.... you literally said to turn it off, and that meets this list's own criteria for removal, so I'm definitely not overstepping anything by suggesting it.

but there are some combinations of compositor and wezterm versions that have some issues.

Right, maybe like I suggested ITT, if not a removal, a warning is in order. Y'know, some kind of action to avoid a bad experience for users. You want to avoid people having a bad experience, right?

There have been recent changes in nightly builds that improve compatibility with more compositors.

As I said, per haps it should be removed "for the time being". When those changes are released, perhaps things will be different. As the app stands at it's current release, not so much. When you can tell people in issues on your repo that they can fix it by doing X, and it's a rare thing, things might be different. When your official response is 'disable wayland', it's not really "awesome wayland", is it?

The author of #101 does not represent wezterm

No, I represent a user of this list who tried wezterm because it's on this list and got his PC all messed up.

That's not what you want for people, right? So some measure should be taken to avoid it, right? "perhaps" a removal "for the time being" or "Perhaps, the app should stay on the list, but with a note added to warn users that Wayland is not officially supported and they may experience bugs?" is hardly overstepping such measures.

Like I said to the other guy, perhaps you'll be more reasonable, let's talk about how to avoid problems for users of this list, rather than how to defend wezterm's removal - those two things aren't mutually exclusive. You don't need to defend wezterm. I said myself, it's the best terminal app out there because it has the best featureset, as far as I'm concerned. But it broke my machine. Let's act like we care when people's machine gets broken, more than we care about an app being on a list.

The other guy provided a grand total of zero suggestions to avoid problems for other people. I like to hope you can beat that record :) I'm all argued out on this one, but I thought you deserved a response, so I'll just unsub and leave it up to you and this list's maintainers to do the right thing by others.

from awesome-wayland.

There's a difference between recommending a course of action and something not being supported.
Just because I recommend not using wayland to folks that want a simpler experience overall does not mean that wayland is unsupported.

I think it is a bit strong for you to open an issue petitioning for removal of a project when your experience does not represent the experience of the majority of its userbase, and to block me from commenting on that issue.

You're taking my words out of their complete context, and that is what led me to open this issue.

But it broke my machine. Let's act like we care when people's machine gets broken, more than we care about an app being on a list.

wezterm cannot break your machine. I do care about the experience of my users, but if their response is to not to engage with the community on their issues and instead petition against the project, what am I to do?

This forum is not the appropriate place to discuss wezterm issues. If you'd like to open an issue in the wezterm repo we can follow up specifically on what you encountered; I'm sure the owner of this repo would appreciate not having so much drama here.

from awesome-wayland.

There's a difference between recommending a course of action and something not being supported.

When that recommendation is to not support it and is the only resolution, no, there's not a difference.

I think it is a bit strong for you to open an issue petitioning for removal of a project when your experience does not represent the experience of the majority of its userbase

This isn't about your userbase, it's about this project's userbase. It doesn't matter how many people are dong just fine, if there's a real risk that you will have problems, which there clearly is given all the cases about it (you said yourself they are "numerous") and all the commenters (keep in mind how many people are reading it because they had the same problem and NOT commenting because it would be redundant/spamming/nagging, like I was) then something should be done to avoid that happening to someone.

to block me from commenting on that issue.

I literally just told you that I didn't do that and I thought it was unfair. It's literally the first thing I said to you. I try to do you the respect of having the conversation you were blocked from, and you don't even do me the respect of reading what I wrote.

You're taking my words out of their complete context

I literally linked to them, there couldn't be any more context.

wezterm cannot break your machine

It can and did. I had to kill it from a TTY to get my system to respond. (no big whoop. easy fix, for people like you and me, but I'm not living with my head up my rear end in a world where everyone can do that. Noobs exist, and they rely on lists like this one. Try to think about THEM.)

I do care about the experience of my users

And what of the users of this list? This isn't about wezterm, you gotta stop being so defensive and think about other people, you're doing the same thing the other guy did.

if their response is to not to engage with the community on their issues

You want me to create a dupe of a case you already directly responded to with a conclusion? There was no engagement necessary, in fact, it'd only have been spamming/nagging if I had. Others who did engage with you on the topic had their cases closed as dupes, and rightly so.

and instead petition against the project, what am I to do?

I'm not petitioning against that project, I'm petitioning FOR users of THIS one. Not a single thing said by either of you has been anything that would be a change to provide a better experience for people here. All you care about is wezterm and think this is all about wezterm. It's not, it's about people who read this list. It's about some poor rando noob who finds this list and clicks links and copypastes commands and suddenly they can't type and they don't know what to do.

I'm sure the owner of this repo would appreciate not having so much drama here.

And so would I!

So stop making it and come up with a solution for users of this repo to not have a bad experience trying something that is known not to work. All you guys do is argue and defend wezterm and you do zero to come up with an actual helpful solution. I understand you care about your project. It's bloody amazing and obviously still getting better, you have surely worked incredibly hard on it, and defending your 'baby' it is the right and admirable thing to do. But not to the point that it comes at the expense of others. You should be very proud of it, but your pride is so excessive that it's getting in the way of you being considerate. I had hoped that unlike the other guy you'd try and be productive in finding a way for others to avoid a bad experience, such as the numerous alternatives I've come up with, but again all I'm getting is arguments that clearly come from massive bias.

This forum is not the appropriate place to discuss wezterm issues

It's not, and I'm not. I don't need to, since that discussion already occurred, several times, I linked to it. I'm discussing an issue with this list, which is that it gave advice that caused me a problem. You're so busy trying to defend wezterm that you're incapable of considering other people and it's not cool. You can change that if you like. It starts with something like:

"Wow bro that sucks I'm sorry you had a bad time and I wouldn't want that to happen to someone else either, because I care about you and them. I'd really like wezterm to stay on this list though, I've worked really hard on it and it's place on this list means a lot to me, and like you say, it could be good for some people - but I recognise there's a problem, so instead of removing it from this list, how about we (fill in this blank with something that isn't about saving wezterm from a short vacation from this list and is about saving some random internet person from having a bad time)"

You could do that. You could care about other people as much as your project and find a mutually beneficial solution instead of making "drama". In theory.

from awesome-wayland.

've just finished reading through both this and the other thread.

Appreciated, and apologies for all the 'frayed edges' you've waded though.

Possible solutions...

1. We could remove Wezterm from this list entirely. That feels... not good to me, and unfair to @wez and team, given the above answers.

Agreed.

2. We could put a warning/disclaimer next to Wezterm on this list. That could work, but isn't really an approach I want or precedent I want to set for the sake of maintaining this list.

Smart move. The list is awesome and making it hard work to maintain would suck for you and then everybody suffers.

3. Lastly, here's my idea, taking a step back from Wezterm specifically. Looking at the two other GPU-accelerated ones on the list, I see some similar issues (ref: [alacritty issues](https://github.com/search?q=repo%3Aalacritty%2Falacritty+wayland&type=issues&s=created&o=desc) & [kitty issues](https://github.com/search?q=repo%3Akovidgoyal%2Fkitty+wayland&type=issues&s=created&o=desc)). I could add a somewhat more general blurb at the top of the [Terminal Emulators](https://github.com/natpen/awesome-wayland#terminal-emulators) section that notes that GPU-accelerated terminals are often more bleeding edge or ambitious endeavors, so take care when going down that route and be ready to potentially troubleshoot your way through getting things working.

That ought to do the trick! I hope @wez would find that agreeable. If not, I'm sure we can find some other solution if we work together toward it.

Thank you again for all the discussion so far! Please feel free to let me know it you're opposed to solution (3) or have other ideas. I'll think through this some more today and let it percolate, to see if any other good ideas come to mind.

No, thank you. I just wanted to solve a problem for random interwebs user #6480 and you ended up having to read a novella. I do appreciate the effort.

from awesome-wayland.

Thanks @natpen, I think option 3 is reasonable.

The other options are undesirable because the reality is that so much about software is ephemeral as various dependencies are changed and updated. For example, for much of the past month I've been unable to run a video call more than once per reboot due to some weirdness after running a routine software update on Fedora 38. Does it mean that Fedora should be removed from a hypothetical list of systems that can be used to make video calls? I don't think so.

Furthermore, if you single out a piece of software it is then a burden on someone to identify/track and update and maintain that listing, and I think we can agree that no one really has time for that.

from awesome-wayland.

It seems as though, in a search for a solution, we've fallen afoul of tarring one project with another project's brush. Sorry @kovidgoyal, I've been using kitty without any technical problems at all on Wayland for some months. It's only the no scrollbar design that has made me leave it. So I don't like to see kitty being unfairly labelled. It's good, working software, as evident from my own experience, and also from your short issues list.

3. taking a step back from Wezterm specifically. Looking at the two other GPU-accelerated ones on the list, I see some similar issues (ref: alacritty issues & kitty issues).

I must confess that I read this and took it on face value but didn't click the links, when I agreed to the proposed solution. If we filter those lists by open cases it's clear that Kitty is not really worthy of a warning blurb. Likewise I looked at foot, another GPU-accelerated terminal I've decided to use (so far without problem) and the issue list contains only one open wayland-related case, which has a workaround in place and seems moments from being resolved.

Given this new (to me) information I no longer feel that the blanket warning for all GPU-accelerated projects is appropriate. Having looked a little deeper, I really think it's unfair to label all the GPU-accelerated terminals with the same warning, when it appears that warning is only really appropriate for two of them.

But, as Kovid put it, to "verify and curate" the list might be something which would cause excessive load on @natpen. It's good to have a list like this, good for the whole community, and it would be a shame to have the list become an excessive load on its maintainer.

Perhaps the best thing here is to spread that load across a wide base - by delegating confirmation of the functionality of the software, to the users of the list. In other words, as Kovid put it, "maybe stick a big disclaimer on top of the entire list", that users of the list (ie, people like me) should check the issues list of any software they intend to try, to confirm that it will suit their requirements, before they install it. This achieves the goal I have in mind of avoiding a bad time for users of the list, without specifically pointing out any individual apps as being problematic, which avoids the problem that @wez and other software developers would have of being deemed unworthy of being on the list, and avoids an excessive load on @natpen so that his list can stay here for the benefit of the community.

from awesome-wayland.

Thanks, everyone. I like the suggestion to just add a bolder disclaimer to the top of the list, and have just done so!

from awesome-wayland.