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