It's not going to happen in GTK4 because it would be an API break and GTK4 has already shipped. So that's why it will have to wait for GTK5 or greater.

Edit: For further explanation see here for a longer description of GTK's release strategy. https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta...

See? I’ve complained to the Gtk devs since before the release of Gtk3 that this would be an issue, I’ve even made suggestions how to avoid it, and yet despite all that all I’ve got were "it’s unnecessary" for years. And now the issue is baked in, I’m supposed to wait for even more years and spend lots of time to fix the issues other idiots made because they couldn’t listen.

In my experience you can't really tell open source developers what to do, you can give suggestions, but if they don't agree with you then the most effective way to get your point across would be to write the code yourself. Also, if you want someone to listen to what you have to say, I would recommend against calling them idiots and other insults.

If every day every single interaction with your computer becomes a pain purely because of some stubborn people who refuse to listen, it becomes very hard to stay calm. Especially after almost a decade.

I'm really not sure I understand, you don't have to use GNOME or Linux. Don't put yourself through any unnecessary pain. Also please remember that nobody is obligated to listen to you in open source, participation is entirely voluntary.

I can’t reasonably do dev on windows, I’ve tried.

So, I have to use linux.

And I have to use something which supports my 27" 4K monitor at 1.5x scale today, not at some point in the future.

I can’t just not work until this is fixed, I have to deal with what broken tech exists today. Sadly.

Again, it is not a matter of new API! New API solves exactly nothing. It won't solve the libXaw/Motif/GTK2/GTK3/whatever apps. They still have to run correctly.

Your new API won't be adopted by everyone overnight, that's why it is a dead end.

Those old toolkits can just be be deprecated (most already are). Most of them don't even run on Wayland: by rendering through XWayland, they will be blurry anyway. You can just continue to have a fallback path that just makes a blurry mess.

GTK3 is the exception but you can just let it be blurry; everything else can be sharp.

Sure, they are deprecated, but Xwayland has to display them at correct scale, still.

One of the issues in X11 is, that the display server can tell the clients what the screen dpi is, but it never knows, whether they honor it -- and they never tell. Many of them don't, some do, so you cannot have uniform handling for them, and if you find a mechanism where they can tell, how do you retrofit it back? You won't.

So yes, putting the mechanism into current toolkit is easy, but that means that the linux desktop is going to be broken for decades to come, because the old client won't disappear overnight. If they did, we would be in pure Wayland for years already...