[crashdancer]

Sorry but that's a really poor example and IMO not a valid complaint. I don't think they made the wrong decision there. There are quite a lot of other API changes in GTK4 so some tiny shims for only a couple APIs wouldn't help in porting at all. It would only create confusion because there would be two APIs for the same thing but now it's even more unclear when the old API is going to be removed. The argument you're essentially making here is "keep deprecated APIs around forever" which isn't realistic. They're deprecated for a reason, if you never remove them then deprecation isn't meaningful anymore.

Also you're incorrect that it would be "just a few lines of code." Those things are GObject classes which can be referred to in various ways through the runtime system or by language bindings, it's not just a matter of creating some aliases for C symbols. If you only use those in such limited ways that a tiny shim would do the job, then it would be just as easy and more beneficial to create a small script that does search and replace on your entire project.

It would be entirely possible to create a larger shim to ease porting, and keep it outside the main project so it doesn't cause confusion. But for it to be truly useful, someone would have to put a lot of thought and effort into making it work for a good portion of the APIs that changed. Then it would have to be tested thoroughly with all the language bindings. It's a way bigger project than just shipping a couple of #defines in a header. And if it did exist, it too would get deprecated and obsolete at some point when all the apps finish their ports to the new version. None of this is a new idea -- all this I'm taking about is exactly what Qt already did with Qt5Compat. It could be done in GTK as well but some interested party needs to make it happen. So far, no one has cared enough to put their money where their mouth is and actually do it.

BTW even the Linux kernel does a thing now where they don't use deprecation attributes in the code at all anymore. If a kernel developer intends to remove an API then they just delete it and fix the build. Because in practice it's actually much worse to keep an API around for long past its expiration date and annoy everyone with deprecation warnings.

[gapan]

Your comments show that you have a close understanding of technical details and processes used in the Gnome project. I believe you should come clean about what your relationship with the Gnome project is. As other have hinted, you do not seem like the impartial external only-just-a-user you claim to be. You clearly have an agenda.

You only registered an account yesterday and have only commented in this thread. Most of your replies include comments like the following:

* This seems to me a very bizarre request.

* That doesn't make sense.

* See, I think now you are being too overly dramatic.

* Perhaps that's proof that it isn't as bad as the vocal minority says it is?

* It's odd you say those things...

* Sorry but that's a really poor example and IMO not a valid complaint.

* Please avoid this narrative.

* You're disrespecting yourself and the readers of your comments by making these kind of hyperbolic statements.

* The issues you mention here are mostly not relevant anymore...

* Speak for yourself please...

That shows a pattern. You seem to dismiss everything everyone else is saying. Considering the history of attitude of Gnome developers towards users and their requests, this leaves little doubt of your connection.

[crashdancer]

I don't have any relationship or agenda. If you really want to know, I had an account here long ago but I received some very rude, hateful and harassing comments so I stopped posting and then lost the password. Is it that much of a stretch for you to believe there's a GNOME user who isn't angry at the developers and doesn't share your opinion? I don't get my FOSS news from social media. I read the developer's blogs and announcements directly and I don't assume they're lying or trying to hide some secret evil agenda, perhaps that's why you see contrasts between my attitude and the attitudes of others?

>You seem to dismiss everything everyone else is saying.

But disagreeing with something is not a dismissal. In cases where I disagree I'm careful to state the exact reasons why and discuss, or present some facts or explanations that someone may have overlooked. That's how to keep the discussion engaging even if you disagree. I'll only dismiss someone if they're intentionally rude. And this comment is against this part of the guidelines: "Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken." I don't have any way to advance the discussion when you do that, it's personally attacking and putting me on the defense when I haven't done anything but state my opinion. Can't you see how that becomes a way to systematically shut down discussions and make them hostile, when someone constantly throws those accusations at strangers?

>Considering the history of attitude of Gnome developers towards users and their requests

There is no free software project anywhere that is obligated to honor any user's requests. If you have a problem with this, you should not use FOSS. But if you absolutely need someone to honor your requests, you need to pay them and get the contract in writing so they're legally required to do so.

[the_biot]

The Linux kernel changes internal APIs, and whoever changes it gets to fix the kernel code that relies on it. The end user of the kernel -- user space -- never sees any of this, and the userspace API never breaks.

You're implying this is equivalent to GTK and Gnome intentionally breaking API with every major release for every applicaton that uses those libs. It is not. Frankly it's a bad faith argument.

[crashdancer]

>The end user of the kernel -- user space -- never sees any of this

I mentioned it because despite that difference I don't think it's practically much different from a developer perspective. Big changes are still about as organizationally difficult for kernel developers to do. If someone wants to deprecate something that a lot of other people are using and it's a lot of work, then they still have to convince everyone to go along with it, get them onboard with the new API and help out with removing the old API, etc. That's the actual hard part, sometimes it can be made easier by providing a shim but often it's not.

>the userspace API never breaks

This is an aspirational statement, not a rule. It has been broken lots of times. The userspace API in Linux is not just the syscalls. Effectively it encompasses every single thing a driver does and exposes in some fashion to userspace and a number of other things as well. Whether that be ioctls or other non-standard interfaces exposed by block devices, sysfs entries, procfs entries, other pseudo filesystems, netlink events, configuration files, low level userspace libraries like libselinux and libseccomp et al that technically aren't part of the kernel but the kernel developers encourage everyone to use them anyway, util-linux and other utilities of that nature, you get the picture. This stuff changes all the time and it's not even possible to keep it all stable forever because it's such a massive amount of code.

>You're implying this is equivalent to GTK and Gnome intentionally breaking API with every major release for every applicaton that uses those libs. It is not.

Yes you're correct that it's not exactly the same but I'm implying the exact opposite: The GTK and GNOME changes are actually much less of a problem! You can have many versions of those libraries installed at the same time. You can't easily use many different kernel versions at the same time.

>Frankly it's a bad faith argument.

It's against the guidelines of this site to make this kind of statement. And quite frankly it's very uninteresting to respond to. You can make your point without this.