The non-compatibility has over the years become the defining feature of GTK/Gnome. The maintainers seem to go out of their way to break API, for no reason at all. That extends to Gnome applications as well.

I recently found a GTK API call that was deprecated in GTK 3.0, only for its replacement to be deprecated by 3.16. These are not thoughtful people, with a vision for the future. They are idiots that inherited something great (GTK 1), and have spent decades thoroughly fucking it up.

▲

badsectoracula 3 days ago | parent | next [-]

IMO Gtk2 is better than Gtk1 as it did a significant number of improvements both in terms of features and usability. Later versions though aren't as great.

And TBH i do not think Gtk was ever "great", it was just fine and its main feature was availability because of the C API. For some time it was also the de-facto GUI API (during Gtk2 times) for Linux until Gtk3 broke that.

▲

tuna74 3 days ago | parent | prev | next [-]

Deprecated does not mean removed. Was there any actual API/ABI changes in GTK3?

Also, it is easy to call people idiots, but calling people who GIVE you software you can choose to use or not that is not very productive or even nice.

I could call you names but that would only make this discussion worse.

	▲	3 days ago \| parent [-]
		[deleted]

▲

hulitu 3 days ago | parent | prev | next [-]

> The maintainers seem to go out of their way to break API, for no reason at all. That extends to Gnome applications as well.

This is also true for KDE and, unfortunately, a lot of modern software. People just don't like building and fixing things.

▲

freedomben 3 days ago | parent | prev | next [-]

I absolutely share your frustration at breaking API changes, and the older I (and my software) gets, the more it irritates me. It can be downright enraging to have (my) perfectly working code suddenly broken due to an irrelevant (to me) API change, especially when it requires hunting down a ton of compiler errors. I absolutely wish they would prioritize stability more.

Now that said, I do not think the truth is "The maintainers seem to go out of their way to break API, for no reason at all" or "These are not thoughtful people, with a vision for the future. They are idiots that inherited something great (GTK 1), and have spent decades thoroughly fucking it up." Having worked on numerous long-lived APIs in the past, there is always a tension between backwards compatibility and future development, especially consistency between calls. Especially when there are a lot of different contributors, it's very easy for annoying inconsistencies to pop up, and it feels really great to fix those. It's a constant balancing act between the past and the future, and a tilt too far in one direction comes with some significant downsides. I also think some grace is warranted for people giving their code away freely with no expectation in return.

▲

thw_9a83c 3 days ago | parent | prev | next [-]

I wouldn't say that maintainers break API, "for no reason at all", but surely they don't make the stable API a priority either. The fact is, that every API breaking change is an insult to developers/users of that API. But this is an unfortunate state of the Linux desktop.

▲

the_biot 3 days ago | parent [-]

Yes, no reason at all. I submit as evidence gtk_hbox_new(), there since the very first version of GTK, and deprecated in 3.2, in favor of gtk_box_new(GTK_ORIENTATION_HORIZONTAL).

It's a prime example of something that was entirely unnecessary, could have been hidden from the user with a macro, or (pointlessly) added but keeping the old API in place.

They do this all the time. It's not just the idiocy, it's the blatant hostility towards their users that gets me.

▲

rleigh 3 days ago | parent | next [-]

Yes, this is a prime example of completely gratuitous breakage.

The change adds zero value. It's a deliberate API break. And it could have been made a non-breaking change all for the sake of a single one-line macro or inline function.

This isn't unintentional. It's a deliberate choice they have made. And not just this one, it's happened repeatedly over the years.

The thing that really gets me, as an end-user/developer, is that it forces incompatible changes not only in my codebases, but in every other application developer's codebases worldwide. A small change in GTK+ imposes hundreds of thousands of man-hours of maintenance work upon every application developer. And this burdensome work not only takes time, effort and money, it doesn't improve our applications one iota, and on top of that, it breaks backward compatibility so our code will not longer build with older GTK+ versions. Most of us won't be chasing the latest development release, applications might need to target a wide range of distributions with a wide range of GTK+ versions. So it's a logistical nightmare as well.

The lack of concern for the needs of actual application developers is why I eventually had to give up on it entirely. At some point it doesn't make any sense either commercially or for free software development, it's just masochism.

	▲	joz1-k 3 days ago \| parent [-]
		I completely agree. This comment should be carved in stone for future generations to see. API breaking changes should never be made just to chase illusory butterflies.

▲

thw_9a83c 3 days ago | parent | prev | next [-]

This is sad. Actually, a long time ago I stopped working on two Linux desktop applications that used KDE framework libraries. I managed to port them from KDE1 to KDE2, but I got frustrated and lost my patience with KDE3 changes which had nothing to do with my application and I just gave up. Sorry to hear that GTK is the same constantly changing target. After this experience I actually like Web-UIs and CLI apps a lot more.

▲

Sophira 3 days ago | parent | prev [-]

Sounds like the work of architecture astronauts: https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

▲

spookie 3 days ago | parent | prev [-]

The best part is having no good alternative to the deprecated stuff.

In the end I just stopped giving a damn and use either a modified microui or lvgl.