Qt4 applications will run perfectly fine on modern Linux distros assuming these distros have Qt4 available (let alone installed since Qt isn't as common as Gtk to be considered something you can rely on being installed on any desktop installation). Qt4 is dead from its developers perspective and because of that it will be removed, like Qt3, Qt2 and Qt1 before it. Debian, Arch Linux and others have plans underway to do that. After that is done, Qt4 applications will not work unless the user decides to manually install it (which most likely will imply compiling from source - and good luck solving any incompatibilities between Qt's massive codebase and any of its numerous dependencies - after all it isn't just Qt that breaks backward compatibility, some of its dependencies can and will break it too).

Same with Gtk+2. Once Gtk+2 itself is removed - like Gtk+1 and Qt4 before it - from the repositories, Gtk+2 applications will also stop working. Similar case with Gtk+3 now that the Gtk developers are working on a yet another incompatible major version, Gtk+4.

Also keep in mind that even though the major versions of Gtk+2 and Qt4 were released years ago, applications are still being written and released using those versions (e.g. Lazarus applications to this day are released with Gtk+2 as the Gtk+2 backend is by far the most stable - the Gtk+3 backend is still in alpha state, due to the low manpower that the project has - note that this manpower wouldn't need to be wasted if Gtk+3 was backwards compatible with Gtk+2 and instead all that time would be spent in stabilizing and improving Lazarus, which shows how much developer time is wasted when libraries many others rely on break backwards compatibility).

Now sometimes someone will suggest that applications should bundle their dependencies with them, but this introduces other problems - like the bundled libraries not using any features or fixes or having configuration mismatches with the libraries already installed on the system. This is a worse situation since instead of potentially addressing forward compatibility (you wont know for sure if the developers of the systems you rely on wont promise to not break your application) you are breaking current compatibility.

It sounds like you are just airing your general grievances about Gtk2 and Qt4. The fact is, you claimed X11 with Gtk/Qt wasn't "sane", because sane platforms like win32 "will still remain around even if it wont get updates as doing otherwise". Gtk2 and Qt4 are still around and up-to-date packages are available for all major distros.

And your last paragraph sounds like you don't really know what you want. Do you want old applications to run exactly as is (which is solved by bundled dependencies), or do you want their developers to update them forever for decades and decades (which is solved by abandoning old toolkits)?

Finally, none of this even touches the fact that your "sane" win32 platform has incompatibilities too and there are many, many old win32 apps that doesn't run in modern versions of Windows.

> The fact is, you claimed X11 with Gtk/Qt wasn't "sane", because sane platforms like win32 "will still remain around even if it wont get updates as doing otherwise".

"...as doing otherwise will break all the applications that rely on that tech that people bought and rely on". Do not remove the important bit.

Also i wasn't only referring to Win32 as Win32 does get updates, though they are minimal.

> Gtk2 and Qt4 are still around and up-to-date packages are available for all major distros.

For now. But as i already wrote several distros like Debian (and thus any that depend on it) and Arch are planning on removing it (just like they did Qt3, Qt2, etc). I already wrote that, why are you responding as if i didn't already addressed the issue here?

> And your last paragraph sounds like you don't really know what you want. Do you want old applications to run exactly as is (which is solved by bundled dependencies), or do you want their developers to update them forever for decades and decades (which is solved by abandoning old toolkits)?

It only sounds like i don't know what i want because you see only "which is solved by bundled dependencies" and "which is solved by abandoning old toolkits" as the only possible solutions. I didn't brought those up because they are the only possible solutions, i brought those up to explain why they are bad solutions (something i'm not going to repeat, i already wrote that).

Another solution, which i have repeated multiple times, is for the libraries to not break backwards compatibility. If the libraries do not break backwards compatibility then you can simply link against them dynamically, rely on them being there and provided by the OS (or at least ask for them and expect the OS to be able to provide them) and you wont need to bundle anything (the library is provided by the OS) nor worry about breakage (the application will keep working because the library wont break).

I mean, it isn't rocket science, it isn't dreamland, it is something already happening in both Windows and Linux to an extent. On Windows is the USER32.DLL et al, on Linux is the C library, libX11, libGL, etc. What i'm saying is to extend this to the libraries that also provide a full UI, not just the lowest levels.

> Finally, none of this even touches the fact that your "sane" win32 platform has incompatibilities too and there are many, many old win32 apps that doesn't run in modern versions of Windows.

Yes, there are incompatibilities but Windows is still trying to be backwards compatible and for the most part it succeeds in doing so. I have a lot of older software that work perfectly fine under Windows 10, either by themselves or via minor tweaks. Any incompatibilities that are the aren't because Windows developers didn't try, it is despite their efforts.

On the other hand incompatibilities with Gtk, Qt and now macOS are there because their developers explicitly and intentionally decided to break their APIs. They do not even try (Qt would have a hard time due to it being a C++ API, but Gtk has no excuse).

Lazarus was also amusing for shipping a Carbon backend for macOS until very recently - and then telling people to just use Qt5 while waiting for a proper Cocoa port.

Yeah AFAIK there is only a single programmer who primarily worked on macOS support and he had to work on both the Carbon and Cocoa backends.