md8z

All patches have a maintenance cost, different projects have different thresholds for what they will accept and what they won't, that's completely ordinary. Not anything I've seen specific to GNOME or KDE or any other project. You can shop patches around to see if various other people want it but if nobody wants it, then maybe it's a problem with your patch.

Some features I used have been dropped too, I just adjusted my workflow to the new way. It's not hard to do, especially if you are already used to switching desktops.

IMO it is bad form to laugh at developers and hope a project becomes obsolete, I doubt you will win any friends or change any minds that way. It's not personal against you if someone declines to implement a feature.

I really can't agree, the GNOME stuff I've used as a developer has been great for me. Keep in mind that no software project will ever be able to accept all possible feature requests or pull requests, for example I wouldn't expect System76 to accept everything that comes their way either. They have a specific design they're trying to meet too and that requires focusing on some things and disregarding others. I don't think they are trying to aim for something that is so good that it obsoletes everything else, that's unrealistic, you would have to invest a really large amount of money to even have a chance of doing that.

That isn't really true IMO. I don't think anything they are trying to do would be impossible with GNOME or KDE. But I get it, people need to put in the time to work with upstream, and for some who just want to ship products, that's not convenient.

That crowd is not new. There are numerous other desktops and they've been around for quite some time. In my view, none of them have ever come close to GNOME or KDE in terms of velocity. Also, it seems that few of them are even trying to provide a comprehensive app platform, or if they are, it consists mostly of repackaged things from GNOME or KDE.

I don't understand the question you are asking. Yes, if you configure GTK to load some CSS, it will do that. However that won't guarantee you see the correct styles, because CSS is technically not able to do that in all cases. If there are bugs in the the Pop_OS theme then it will continue to be broken, see the images at the bottom of the article...

Edit: I kind of alluded to this before but I want to make it clear, if you are trying to make it so the user can safely load themes without "special modifications to the app or compile process", then CSS is probably the wrong choice. It is not suited to do that, CSS is only safe to use when modifying the app itself, or if you are shipping a theme as a build-time dependency in the form of a library (i.e. libadwaita). So that's kind of why your question doesn't really follow to me.

It's not the plan though. You can still inject global styles into libadwaita apps. It continues to be as bad an idea as it was before. I'm happy to provide details here.

Well there is no marketing department, so AFAIK the designers have to balance doing blogs and press releases with all their other work which is not easy to do. It is a non-zero amount of work to explain it. If you just want to have a quick conversation about it and are interested to get involved with design then I think it would be faster to do that than trying to get them to write an entire blog article or something.

I see all that, but the issue is fixed now. Yeah they made a design mistake and then they corrected it, it doesn't seem to be much different from any other bug. If you are trying to get help with something, it is not particularly useful to cherry pick comments from a long time ago that are not even relevant anymore. I'm sure we could go through the old bug tracker and find various disagreements in other areas, but that won't really help with the status of a current bug.

Dell does already ship a laptop with Ubuntu installed. No I don't think Best Buy and Walmart carry it, because the only target market for it is developers. I remember seeing lots of cheap netbooks that had a Linux option but no stores carried them because nobody besides developers and geeks actually wants that.

"So open discussion is not accepted, changes to the plan are not accepted because they're volunteers and can't accomodate everybody, merge requests are not ideal because they don't have time to review them."

Please avoid this hyperbole. If you actually look, there are plenty of examples of changes being accepted. But you have to play ball with them, like I said you can't just throw code over the wall and you can't just barge in and start trying to pick a fight with someone about the design.

"There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere."

If you have advice from those projects on how to improve process to make it easier to do it then please mention that. But otherwise I really don't know what you mean, I have had issues and merge requests ignored/declined in basically every open source project I've ever contributed to.

So your solution would be to not participate at all, ensuring that what you want has a 0% chance of ever getting done? Can't you see how that is strictly worse?

And yeah, of course the number of people who can do it is limited, not everyone is an expert in this stuff or has an interest in becoming one...

It is no different from the "politics" you play at work every day. Your coworkers have to like and respect you (on some level) and you have to like and respect them or you will probably have a bad time. If you are new your boss probably won't give you the root password to the production database immediately, you have to work up to it and become senior within that company.

It's not clear what you want otherwise, if you want other projects that have a lower barrier for contribution, there are plenty of those, and they also have huge backlogs in their issue trackers. I mean just think of this from the other perspective. Say you are maintaining an open source project in your spare time. Somebody comes along and asks you to do something that would take up months of your time. And the fix is somewhat complicated so instead of spending your free time with your spouse/kids/friends/etc you would have to spend it all on that fixing that issue, for months, during which no other issues can be fixed. You could close the issue with an explanation, you could say you want it eventually and then leave it open, or you could totally ignore it and leave it open. But none of those options will ever be satisfying to the reporter, sometimes people just ask for things that are not realistic. I'm sure you can relate if you have paying customers at work that have ever asked for unrealistic timelines...

I really don't agree with any of what you said. I have never been part of any internal clique and I've gotten patches in. The "examples" that I have seen posted around are bugs that get posted to hostile places like certain subreddits which then go and brigade the bug tracker which pisses everyone off. If you're having problems influencing people then you may have to get to know them first and learn what motivates them, it doesn't really make sense to skip this step and then sit on the sidelines complaining that nobody is listening to you or spending their time looking at your patch. If you cannot convincingly explain how your patch is going to help upstream then you have already failed, and that's the way it is with every open source project I've ever seen. It's a collaboration, it's not just dumping code over the wall.

I also don't know what you mean "volunteer excuse", it's not an excuse, that is the truth. Those people are unpaid volunteers doing it in their spare time, you deserve to know that so you don't get the wrong expectation. If they lack time or motivation to review a backlog of issues and merge requests then dumping more merge requests on them is probably not going to help. I'm sure you can think of other ways to help out there if you're really motivated.

"it is what they do that matters and ever since Gtk3 they basically took over Gtk."

I don't know what else to tell you. If you follow what is happening in GTK4 you will see that they are moving things out of GTK. This is what they are doing at this current point. Also I hope you understand that this stuff is all open source and nobody is "taking over" any projects, it's simply whoever shows up gets to make the decision. It was mostly GNOME that was contributing upstream during GTK3 so that's what happened.

"How is it not clear, i explicitly provided Win32 as an example right after the part you cut at."

Right, if you want Win32 API, you would use Wine for that. But if that's not adequate then please explain. And yes I know there are bugs and missing features in Wine, so that would be the place to start instead of trying to make a new toolkit that would also be incompatible. If you cared about compatibility with old apps then I'm actually very confused as to why you would be asking for a new toolkit, old apps that don't get updated would never use it.

"...Win32 does get new features and bug fixes all the time - even the pre-XP controls (i mean the non-themed common controls) still get updates."

Okay but which updates. If you want something implemented in Wine or you want something backported to GTK 1 or Qt 2 or whatever then you need to mention that. I can't guess what it is you want.

"So you have to bundle the libraries with your application which not only bloat the application itself but also version lock the dependencies to whatever you bundled, including its features and bugs."

This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time.

"it wont get a Wayland backend because the bundled version you have was never updated for it. It also wont get high DPI support for the same reasons"

Ok these are real things to ask for, that someone could feasibly attempt to do. I would say just skip all the other things you asked for, cut out the rest of your comment, and just ask for this, because these are real missing features that could be put into an action item. But actually, I don't think either of these would be technically possible for a lot of apps. If an older app uses Xlib functions then that won't work with a native Wayland backend. If it draws pixels to a buffer and doesn't calculate scale then it won't work with high DPI. (You would be surprised how many older apps actually do this...) So that is unfortunately not something that can be fixed in all cases by trying to backport things to an old API and I think you would largely be wasting your time trying to implement those things. At some point you have to accept that the old APIs are just not suitable for some things.

OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations.

"What i want is simple: a stable ABI so that binary applications can keep working in future (think timeframes of 20, 30 years and more, not just a couple of years or whatever)"

I mean, already I mentioned how it would maybe be possible to get this in some limited form. But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that.

I really don't understand why you are posting this, this is a 9 year old bug that is marked fixed. Please read the rest of the comments on the bug beyond that one and please don't make me regret asking these questions, I'm feeling like my time is wasted when people post these bugs without checking them.

I don't think they have quite enough resources to do AB testing, it seems that needs a pretty big group of people doing it over a long period of time. AFAIK they are only able to do smaller targeted studies.

I'm not sure what you mean they don't have a proper feedback channel. They have all the same ones as most other open source projects: an issue tracker, a chat room, a forum, etc.

I honestly have no idea what you're talking about, I still see an option for "Allow different input sources for each window" in the keyboard settings panel.

Yes, there was data to decide that, you should ask them nicely on the proper channel if you want more info. Please avoid dismissing things as "bullshit", that's rude and it doesn't help the discussion. If you have any additional data to the contrary, then now would be the time to present it. AFAIK extensions are considered as a data point but are not the only one, any time there is a design change there tends to be an extension that reverts it so it's not much of a reliable thing.

That is a misconception. The GNOME designers I have seen are not making decisions at random or removing things because they can, there actually is data and research to back up what they are doing. If you are a designer and are interested to know more then it would benefit to talk to them and ask them for their reasons, and then maybe you could contribute meaningfully from that angle. If there is something you think they missed, and you have the data to back it up (i.e. real usage data over long periods of time from large groups of users), then I think that would be helpful.

Can you please give an example? Keep in mind that if a change fixes some accessibility issues for some people but then causes other accessibility regressions elsewhere, that could also be bad and not wanted. Nobody wants to be the person to make that decision and deal with the angry users, but sadly, somebody has to do it unilaterally otherwise development on the project will not happen.

Really now, if your stance is "it is bad for an open source maintainer to make decisions that might be difficult" then it seems you would have trouble finding any project that suits you.

The amount of misinformation on the net about theming in libadwaita is staggering. Global styling hasn't been disabled. There is nothing there that would really affect them in any significantly worse way than GTK3. That isn't to say they should do it, CSS theming will still be as broken and ill-advised as it is in GTK3, you can see that with the images at the bottom of the article.

"which align with an anti-theming petition that some of the team members support (stopthemingmy.app)"

To me this is a bad way to put it. I don't consider myself to be "anti-theming" and I agree with everything in that petition, except for the title which seems to be inflammatory and has contributed to some of the confusion and upset about theming in GTK. The title could be changed and the petition would be much better, I think. But it is probably too late for that.

I have heard people saying that for 20 years. "We just need to get more OEM preinstalls and then Windows will fail." Meanwhile, various OEMs have come and gone (i.e. they all crumpled under the pressure) and nothing happened. System76 has been around for 16 years, they have their niche but that's about it. Ultimately, they are a hardware company making a distribution that works well with their laptops, and that's all they can really do.

For any of these companies, I would seriously ask them "do you think you can be the next Microsoft or Apple, and if so what would you do to get there". And if the answer has something to do with trying to convince OEMs to install Linux, or trying to ship more random embedded devices, then I probably say they need to come up with a new plan.

They said they weren't going to do that and they would continue to use GTK.

Also, this is wrong:

"because at this point Gtk is a vector for Gnomisms to projects outside of Gnome."

In GTK4 the goal has actually been to intentionally move GNOME specific bits out of gtk and into libadwaita. I can provide a source, if you want.

"one that understands the important of ABI stability over an actual long period of time"

I mean, I hear this asked for frequently but it's not clear what you want. You can keep using Qt 2/3, GTK 1/2 and those are technically "stable" but of course the trade off there is that you don't get new features, or bug fixes. So if you want someone to do something with those, it would help to ask for what you want specifically.

I don't think this is going to help at all. There are already way too many desktops for Linux and none of them are pushing GNOME or KDE to keep up. To me this is just another one to add to the pile sadly. We already went through this whole song and dance with Canonical and Unity and that ended up dead as well.

ChromeOS (and Android) are their own things and not related to any of the other projects. If somebody was building a new desktop and had a few hundred million dollars to spare I would say just do that similar to how Google did it. A company with those resources would be wasting them by involving itself with the open source desktops, those projects are perpetually in a state of being 5-10 years behind. Of course that means they would have to bring their own app ecosystem too.

Just FYI. If your suggestions for "making it better" for yourself would be making it worse for other users, then that probably would be why your suggestions weren't taken. GNOME has made accessibility a priority for a while now, so that is why the interaction with the mouse has been done the way it is. (Disclaimer: I am not a GNOME developer, this is just my observation)

Which LTS distros were you looking at that did not receive security backports?

I can't say that's been my experience, are you by chance using a rolling release distribution?

I used a minimalist WM for many years but stopped because I realized I was just being stubborn and resisting change for no reason. It ended up being more work to constantly keep trying to compensate for things that are missing in such a "minimalist" environment.

If you ask me, it pays to just learn to be flexible and learn to appreciate and work with the strengths of a software even if you don't like some aspects of it.

As someone who has been hacking on desktop stuff for a while, I totally disagree with your comment.

Maintaining a different desktop is a massive undertaking. The total amount of lines of code in GNOME or KDE is comparable to the lines of code in the kernel. It is no joke to make a new desktop environment, to the tune of hundreds of millions of dollars. It's not just a matter of take GNOME and replace the window manager and then you're done. But I suspect that is what System76 will start with and then they'll see how much money they can raise from that. (Probably not much if Purism is any indication)

Backwards compatibility to the kernel only matters to the syscall API. There are areas of the kernel that get quite a lot of churn. Or things such as obsolete/unmaintained drivers and architectures getting removed. But nobody complains about those because it only matters to driver developers or other low-level people like the systemd maintainers. And when something broken does make it into mainline, the few people who get affected by those drivers who do complain get told "too bad, there is no money/time to fix it, buy new hardware or pay a support vendor" or something like that. You know, the usual thing you hear from any open source project. I really don't see how the support culture is much different. I know it's common for people to call out GNOME but I never understood any of the complaints there, you can still grab GTK1 and GTK2 and compile them if you really want to use those, as bad an idea as it may be. Those are about as unmaintained and crufty as any of the older areas in the kernel, and they're still technically around.

I don't really get it. I mean, I hear your frustration, but you're saying you would rather spend your life maintaining a fork? I hope you see how that's also a bad option... How can this be done so everybody wins?