Note that on X, client and server are inverted.

Gtk2 also had exceptionally long lifetime, initial release in 2002 and last release in 2020. In contrast Gtk1 was initially released in 1998 and last release was 2001.

Motif was the real "classic" API. But let's do a little justice to GTK1. Motif was still a proprietary library when GTK1 was released. GTK1 was also already easier to develop with, and the default look&feel was somehow better. For some reason, all the widgets in the Motif UI were huge. Given the small resolutions of that time, it was very space inefficient.

Then I would vote for Motif. But since it predates Linux, it is a classic Unix look, not Linux. For the younger crowd: <https://en.wikipedia.org/wiki/Motif_(software)>

Oh, yes, I remember those early times as well. :) The question is whether it's possible to maintain the legacy API and upgrade the internal architecture to use more modern approaches. I think it's almost always possible, but perhaps the cost to develop and maintain such a legacy layer is too high for an open-source desktop environment and toolkit. The Windows OS managed to support old APIs quite well, but the available resources are incomparable.

Are you sure no antialiasing? No subpixel for sure.

I think I have some rusty memory of LD_PRELOAD my own .so with AA enabled (special patch? I don’t recall) with a game’s installer I shipped to get the statically linked GTK+1.2 Loki Games setup utility looking modern. That plus a QUITE SPIFFY looking splash bitmap slapped onto it would hopefully let the installation complete before anyone realized it was a creaky old thing.

Motif was improved with XFT/Fontconfig support. GTK1 can be patched too'

I wonder how many llm tokens are burned dealing with Unicode issues?

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.

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.

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.

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