[Crysstalis]

The only reasons anything has compatibility breakage is because things have not been back ported, or because no one has built a compatibility layer. GTK1, and most other programs using Xlib, are able to work because XWayland was built as a compatibility layer. If there are other areas where things have broken, then I suggest you try to build additional compatibility layers.

[badsectoracula]

As i already wrote twice in other replies, Gtk breaking backwards compatibility is not due to a force of nature, but due to the Gtk developers deciding to break it.

The backwards compatibility i refer here is having libraries, binaries and code work with the very latest version of Gtk (not Gtk1, Gtk2, Gtk3 or Gtk4, but *Gtk*, no numbers or anything) always work, just like a Win32 binary made in Windows 95 using the Win32 API can work in Windows 11 and even get new functionality introduced in the same APIs since then or just like an ELF binary compiled in a 1997 Linux i386 distribution can work on a modern x86_64 Linux distribution (assuming no dependencies to broken userland libraries, of course) and use new functionality introduced to the same APIs in kernel since then.

[Crysstalis]

Not all features of Windows 11 can be bolted on to legacy Win32 APIs. Some features can but others cannot. GTK is not different in this regard. Some features have stayed the same but others have changed and require porting.

If the suggestion is that GTK should somehow get the same budget that Microsoft has to put towards backwards compatibility, you know very well this is not possible. It would probably not even be wanted, GTK is a lot less popular than Windows.

[badsectoracula]

Win32 programs from 2000 work on the latest Win32 and get new functionality that is exposed through the APIs they used at the time, where that applies.

Gtk programs from 2000 do not work on the latest Gtk, regardless of if the functionality they used from the APIs they relied on would be found in the latest Gtk. Instead they have to be "ported" to the new Gtk, assuming the source code is available, the developers are available and someone is willing to waste effort and time to do the porting.

[Crysstalis]

This is a nonsensical comparison though. New versions of GTK are actually new APIs. So what you are saying is more like "WPF programs do not work if you delete WPF and try to compile it against only the Win32 API" which is also correct. GTK1 programs will continue to work on GTK1, it has not changed.

[badsectoracula]

> This is a nonsensical comparison though. New versions of GTK are actually new APIs.

Which has been my entire criticism! Gtk major versions being "new APIs" is what breaks backwards compatibility and causes existing applications, libraries to waste time keeping up.

It actually worse than Win32 vs WPF because the latter is something you can ignore as Win32 is still receiving improvements with bug fixes and new functionality, but Gtk development for any previous major version eventually stops all development. Not only that but even with new APIs, under Windows there is always some official way to use the previous APIs together with the new (e.g. mix Win32 with WPF) but there isn't anything like that for GtkN-1-with-GtkN (and even if there was it'd be pointless in long term as GtkN-1 would eventually stop working, unlike Win32).

[Crysstalis]

>but Gtk development for any previous major version eventually stops all development.

Then your actual criticism is that those previous versions have stopped development, not that backwards compatibility was broken. The whole thing about "backwards compatibility" is a distraction. And again, it is not a waste of time keeping up if they actually want the new features. If they do not want them then they are free to spend their time maintaining the old versions.