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

No, that's incorrect. It's not more efficient at all, and even if it was it would still be less efficient to do it in the toolkit instead of in a separate shim. I explained this in detail in my other comment.

Also the testing and validation always needs to happen irrespective of where the shim layer is shipped, because this is still a new major release of a relatively large library. Having a shim for one widget out of many isn't going to meaningfully reduce the need for testing.

If you could mention what these programs are that are somehow completing the rest of their GTK4 ports in a small amount of time, refactoring everything to use the new improved widgets and rendering system at incredible speed, but are taking hundreds of thousands of man hours to replace the word HBox with Box, maybe someone can look at them and advise them on how to do that faster.

[rleigh]

You're trying to argue that water is not wet. This is seriously bad-faith argumentation.

Having a compatibility shim in GTK and testing that, once, would save any downstream user from having to do any work at all for this change. This is obvious and self-evident. Yet you seem to think that it's acceptable to impose this upon every user. It's this disrespect for end-users' time and resources which lead to people such as myself abandoning GTK entirely, when it was abundantly clear that it would not, and could not, ever be fit for purpose when you have this type of attitude prevail. Professional library maintainers do not break backward compatibility in such a cavalier manner, particularly when there is zero material net benefit of any sort arising from the change. Why would a project deliberately cause such breakage when it didn't have to. It's because it cared more about making a "cleanup" than it did about breaking it's entire userbase. It's cosmetic at best, and it could have been implemented without any break at all with a bare minimum of effort. That's the real kicker. The change could have been made without any compatibility break. And that just shows a complete lack of care.

Bear in mind also that Gtk*Box are foundational container widgets. Every application of any serious size will likely use hundreds or thousands of them. And no upgrade path for Glade/GtkBuilder XML either. That all needs hand-updating too. And this is just one example of breakage. You have to multiply it by all of the others, too. The ongoing burden of unnecessary and unproductive work repairing breakage arising from API churn is extraordinarily costly. Plus, it also breaks compatibiity of our application code with older GTK versions, which we might well also need to support in parallel for years. None of this adds value to our application, it's all cost.

You've spent pretty much all of your comments here deflecting and prevaricating. You've not once shown any concern of any sort for the actual real-world problems which have been imposed upon others, and which are genuine deal-breakers for actual application developers who have tried to use GTK for serious commercial work. The exact same lack of concern and understanding which the GTK and GNOME developers have shown all along. And I'm not new to this. I've used GNOME since pre-1.0 and developed with GTK+ since the 1.x and 2.x days. I was using GTK+ for commercial products two decades ago. It was barely viable then, and it's many times worse now. The primary concerns of these libraries should be API stability and implementation quality, and they have repeatedly failed at both.

If GTK wants to be considered seriously, it needs to behave seriously. And you need to actually listen and understand what people are telling you.

[crashdancer]

I just realized I forgot to mention this before: that shim actually did exist for about 10 years. It was deprecated in GTK3 and then finally removed in GTK4. If 10 years is too short a warning to give for removing a deprecated API, and this offense is apparently so bad that it ruins the credibility of the whole project, then I really don't know what could be expected of the maintainers.

[crashdancer]

>Having a compatibility shim in GTK and testing that, once, would save any downstream user from having to do any work at all for this change.

No it wouldn't, the downstream users would still have to test. Because in practice there are a lot more changes that need to be made than just the names of those widgets. This is one of those spherical cow situations. It would theoretically save time if apps only used the box containers and never called any methods on them but that's not how real apps are actually built.

>Why would a project deliberately cause such breakage when it didn't have to. It's because it cared more about making a "cleanup" than it did about breaking it's entire userbase. It's cosmetic at best, and it could have been implemented without any break at all with a bare minimum of effort. That's the real kicker. The change could have been made without any compatibility break. And that just shows a complete lack of care.

No, this is all wrong. The container widgets were refactored and heavily simplified in GTK4 to make the API easier to use and maintain because the class hierarchy was getting too deep and complex. Along with that they changed the names because there was a break in the underlying APIs anyway so it was a perfect opportunity to simplify the naming as well. It would not have helped at all to make such a tiny shim, that wouldn't even cover the most basic use cases. Like I already said the shim would have to be much larger to be anywhere close to being useful.

>And no upgrade path for Glade/GtkBuilder XML either.

No, there is an automated converter for the XML.

>And this is just one example of breakage. You have to multiply it by all of the others, too. The ongoing burden of unnecessary and unproductive work repairing breakage arising from API churn is extraordinarily costly. Plus, it also breaks compatibiity of our application code with older GTK versions, which we might well also need to support in parallel for years. None of this adds value to our application, it's all cost.

Then by all means, don't update the GTK version. The reason to upgrade is if you want the new features in the new version.

>You've not once shown any concern of any sort for the actual real-world problems which have been imposed upon others

Actually I just asked for some examples of real-world programs that are having this problem, if you could post the repositories then we can talk about them.

>And I'm not new to this. I've used GNOME since pre-1.0 and developed with GTK+ since the 1.x and 2.x days. I was using GTK+ for commercial products two decades ago. It was barely viable then, and it's many times worse now.

Unclear to me why you've been using GTK for 20 years if it's really that bad.

>The primary concerns of these libraries should be API stability and implementation quality

No not really. The developers can choose that concern but they don't have to. Some projects focus on stability, some focus on getting more features out the door, some focus on other things. I can't explain everything about GTK's decisions but I know that like most open source projects they have to make decisions that encourage certain types of contributions, sometimes that means they have to trade stability. And that also means if you see something that's low quality that you can fix easily then you should start contributing or fork the project, instead of demanding that the maintainers do it for you.

>If GTK wants to be considered seriously, it needs to behave seriously. And you need to actually listen and understand what people are telling you.

I'm not a GTK maintainer so I'm not even the person you would need to convince here. But I am listening to what you have to say, that's why I can tell you with confidence that it wouldn't have helped to make that type of shim.