There are so many that I could spend several hours ranting about them. If you invested time and effort in writing GTK+ 2.x applications, the GTK+ developers sp

There are so many that I could spend several hours ranting about them. If you invested time and effort in writing GTK+ 2.x applications, the GTK+ developers spent zero time caring about API compatibility even for cases where it would have cost them nothing to maintain. They just had to rip it all out just for the sake of it, even when single line compatibility forwarding functions would have been entirely sufficient to avoid breakage. This is the fundamental dichotomy with GTK+. Its developers want to hack on the toolkit itself for their own amusement and occasionally for GNOME features. They don't care about the needs of the application developers who would use their toolkit to write actual applications. God forbid it's used for its intended purpose. If you invested thousands of hours into using it, they will not bear that in mind as they rip out stuff people used for over two bloody decades in the name of "progress". Like GtkHBox. Gone. There since 1997 and used by every GTK+ application on the planet, but that's no reason to keep "old code"! That's their choice. But other libraries like Qt do take better care of the interests of their customers and end users, and don't gratuitously break core functionality on a whim while chasing shiny new things. In the above example, the GtkHBox class is replaced by GtkBox with an "orientation" property. Now, any sane developer would retain GtkHBox and simply implement it in terms of GtkBox with a defaulted "orientation" to horizontal. New way works. Old way works. No breakage. Everyone is happy. But they just had to rip it all out in the name of "progress". Consider how many instances of this there are in a large codebase. Hundreds to thousands in a big UI. The breakage was entirely avoidable and quite unnecessary. Maintaining the compatibility code would have been a tiny effort with a few one-liner compat functions, but ripping it out imposed huge problems upon every user of the library. "Cleanliness" needs to be traded off against "breaking end users", but they have the scale dialled all the way to one side, which is spectacularly unhelpful and inconsiderate. That's just one class and one example. You could write a book enumerating all of the other instances. It's that bad. No one who looks at this rationally in 2020 should be choosing GTK+ for a new project. You know in advance it will end in tears and frustration, as all of the value you created will be destroyed on a whim by developers who should know better, but go ahead and break everything anyway just because they can. That's their choice. But it's our choice to not get sucked into the bizarre world where this kind of software maintenance is considered in any way acceptable or justifiable. Seriously. These people are on another planet. What project intentionally gives the finger to all of their developer base? A really messed up one with nonsensical priorities. Sorry if this comes over badly. If you can't tell, I've got a bit of pent-up frustration after spending far too many hours of my life trying to work around GTK+, submit patches which are ignored, and try to develop applications in spite of GTK+, not because of it. I should have just used Qt from the start.