[Crysstalis]

>they can be exposed in ways that do not break backwards compatibility and instead applications can opt-in to those features.

This is already how it is. If you want those features, then port to newer versions. If you do not want them, then do not port.

>could have been implemented and designed in such a way as to avoid breaking existing applications but also making porting the applications easy.

This is simply not possible. Many older APIs are just not designed to support this.

>then there is absolutely nothing that is affected in that application by improvement to scaling support, CSS support, rendering models or anything else.

Indeed, such a program would probably be trivial to port.

>With what i describe if Gtk4 was backwards compatible with Gtk1, a binary of that application compiled against Gtk1 would run under Gtk4 and get the new file picker dialog instead of the weird one used in Gtk1, would get antialiased font rendering, would get the themes used by Gtk4, etc.

If you want binary compatibility, that is a different story. It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4. But only the most trivial ones like a form with a couple of buttons. Anything with custom widgets (which is all non-trivial applications) would probably break or would lose most/all of the benefits, the GTK1 API simply was not designed in that way.

[badsectoracula]

> This is already how it is. If you want those features, then port to newer versions. If you do not want them, then do not port.

Sorry but this shows you refuse to understand what i write in my responses.

> This is simply not possible. Many older APIs are just not designed to support this.

Then make new APIs alongside the old APIs.

> Indeed, such a program would probably be trivial to port.

And my point is that it shouldn't need to be ported.

> If you want binary compatibility, that is a different story.

It is not a different story, it is part of the entire backwards compatibility story. I refer to not only binary compatibility but also source compatibility. What i refer to is being able to:

1. Run old binaries in new systems while receiving any new functionality that may apply

2. Compile old programs against the latest version of the library without issues (at least not issues due to the library) and get pretty much the same functionality you'd get if you ran the old binary against the latest version of the library

3. Being able to upgrade the program, in parts or in whole (where that'd make sense - a new approach might be "better" in some ways but not be worth the effort for a particular program so using the old approach should still work)

> It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4.

Such a compatibility is only needed because Gtk4 itself isn't backwards compatible with Gtk1.

[Crysstalis]

I understand exactly what you are saying but it does not make sense. Think of this on the most basic level like with DPI scaling. If an application has no idea of DPI scaling and has a certain DPI hard coded in (like many GTK1 applications do) then you cannot do anything about that with any "backwards compatibility". The application will just not work with DPI scaling until it is ported to work with a variable scale instead of a hard coded DPI. You cannot upgrade the program in parts either, or add a new API alongside it. The whole thing must be changed to support DPI scaling or some of it will be in the incorrect scale and the effects will cascade to other widgets that expect the scale to be passed to them from the parent widget. Because remember everything in a GTK program is in a widget tree that depends on passing down state.

Part of the reason that the themes changed and the CSS implementation got changes was because of these issues, i.e. pretty much all GTK1 and GTK2 applications and themes had no concept of device-independence, most drawing was done hard coding a DPI against raw device pixels. The few applications that implement it themselves would not benefit from any backwards compatibility layer.

You can also apply the same logic to many of the other changes in GTK. Your suggestions just cannot be done by swapping out the library, they are either impossible or are even more impractical than the current situation. If it were as easy as you seem to think it is then the GTK developers would have done it by now.