| "it is what they do that matters and ever since Gtk3 they basically took over Gtk." I don't know what else to tell you. If you follow what is happening in GTK4 you will see that they are moving things out of GTK. This is what they are doing at this current point. Also I hope you understand that this stuff is all open source and nobody is "taking over" any projects, it's simply whoever shows up gets to make the decision. It was mostly GNOME that was contributing upstream during GTK3 so that's what happened. "How is it not clear, i explicitly provided Win32 as an example right after the part you cut at." Right, if you want Win32 API, you would use Wine for that. But if that's not adequate then please explain. And yes I know there are bugs and missing features in Wine, so that would be the place to start instead of trying to make a new toolkit that would also be incompatible. If you cared about compatibility with old apps then I'm actually very confused as to why you would be asking for a new toolkit, old apps that don't get updated would never use it. "...Win32 does get new features and bug fixes all the time - even the pre-XP controls (i mean the non-themed common controls) still get updates." Okay but which updates. If you want something implemented in Wine or you want something backported to GTK 1 or Qt 2 or whatever then you need to mention that. I can't guess what it is you want. "So you have to bundle the libraries with your application which not only bloat the application itself but also version lock the dependencies to whatever you bundled, including its features and bugs." This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time. "it wont get a Wayland backend because the bundled version you have was never updated for it. It also wont get high DPI support for the same reasons" Ok these are real things to ask for, that someone could feasibly attempt to do. I would say just skip all the other things you asked for, cut out the rest of your comment, and just ask for this, because these are real missing features that could be put into an action item. But actually, I don't think either of these would be technically possible for a lot of apps. If an older app uses Xlib functions then that won't work with a native Wayland backend. If it draws pixels to a buffer and doesn't calculate scale then it won't work with high DPI. (You would be surprised how many older apps actually do this...) So that is unfortunately not something that can be fixed in all cases by trying to backport things to an old API and I think you would largely be wasting your time trying to implement those things. At some point you have to accept that the old APIs are just not suitable for some things. OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations. "What i want is simple: a stable ABI so that binary applications can keep working in future (think timeframes of 20, 30 years and more, not just a couple of years or whatever)" I mean, already I mentioned how it would maybe be possible to get this in some limited form. But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that. |
These are examples. I'm not asking to use Win32 or add updates to Gtk1 or Gtk2. The important part is keeping ABI and API stability. Also i refer to what i'd like to see in a hypothetical library that did things right, not the current ones that either keep doing everything wrong (Gtk) or even if they wanted they can't due to the tech they're based on (Qt, though chances are even Qt could stay API and ABI compatible they wouldn't because they're primary middleware for paying corporations and only secondary a platform library that happened by chance thanks to KDE).
> OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations.
It is a great example because it shows that it can remain API and ABI compatible for decades. Also both CPU and GPU parallelization could be implemented with extensions (though GPU parallelization is something that GPU vendors seem to be moving away from) in a variety of ways, e.g. using display lists in different threads a per-thread shared context that records a thread-local command list for the operations inside the display list than later can be executed via the render thread. Similarly different contexts can be "bound" to different GPUs and yet allow for resource sharing. Those may or may not need new APIs (most likely will) but are still possible. Or a more low-level approach like Nvidia's command list extension could be used instead.
> But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that.
Well, i'm not explicitly asking for someone to do anything, especially from projects that do not seem to be interested in any of that. My comment was about what i ask for to exist, not what i ask for from someone or some specific project.
Also
> This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time.
This isn't a separate problem, it is a problem that exists because libraries do not have stable ABIs and programs cannot rely on libraries that are on the system to provide fundamental functionality that wont break (or even wont disappear) in a couple of years (or whatever other short timespan).
There is this great commentary by Linus from almost a decade ago...
https://www.youtube.com/watch?v=Pzl1B7nB9Kc
...where he went into the issues and yet they are still there because instead of trying to fix the problem at the core (which is what he explicitly mentions about ABI stability, like it is done in the Linux kernel - BTW this also would be a good example), the developers who work on these projects instead decided that the best solution isn't to decide and stick with a stable ABI but instead provide a standardized form of the "bundle your own libraries" approach - which barely solves anything related to not having stable ABIs.