[rleigh]

Yeah. It really does take more effort to leave perfectly working functionality in place than to do the work to remove it.

Come on. Many of the decisions made by the GTK+ developers are utterly unjustifiable.

Take the removal of GtkHBox and GtkVBox in place of GtkBox. A couple of shims for backward compatibility would have taken just a few lines of code and would have avoided a hard compatibility break. Did that happen? No. So a huge burden to update every GTK+ application (incompatibly!) was imposed upon every developer on the planet. Was that a productive use of resources? No. It was an utterly illogical change which had zero real-world benefit to anyone. And that's just one of many, many bad decisions.

There are very valid complaints to be made about GTK+, and you can't handwave them all away with some PR comments.

[jandrese]

Couldn't you just make your own macros?

    #define GtkHBox(x) GtkBox(x, GTK_ORIENTATION_HORIZONTAL)
    #define GtkVBox(x) GtkBox(x, GTK_ORIENTATION_VERTICAL)

I thought the change to a standard GtkBox made sense given the way the system was built. This made both kinds of boxes the same class, avoiding an unnecessary layer of inheritance.

[rleigh]

Yes, you could.

But this needs doing in every single downstream user of GTK. Far more efficient to do it once, in the toolkit itself.

This is why sane people don't use GTK. The maintainers literally couldn't care less that their 2 hours of "work" doing the removal causes hundreds of thousands of man-hours of refactoring on the part of others, plus the testing and validation work to prove that every part of their applications are still working correctly.

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

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