> You don't get to modify apps -- that's exactly part of the problem being solved; your solution has to work with whatever user throws at it; from Chrome to xeyes, sorry.

That's not how open source works. We get to modify apps. That's the whole point.

> That's not how open source works. We get to modify apps. That's the whole point.

1) people are running all kinds of applications on Linux, not just open source ones. The solution has to work with Siemens NX or Autodesk Maya just like it works with Gtk Demo.

2) Even if you can modify apps, are you going to modify them all? No, most of them would be never fixed.

3) so you are mistaking "we get to modify apps" with "we get to rebuild the world, and everyone's system is part of the rebuild".

> 1) people are running all kinds of applications on Linux, not just open source ones. The solution has to work with Siemens NX or Autodesk Maya just like it works with Gtk Demo.

Applications which are extremely performance critical and accuracy-critical, where the compositor shouldn’t touch rendered pixels at all? Yeah, that works great, right?

We can just enforce the functionality in all new toolkits and deprecate old ones. Existing, old software will just render badly, like it does today, and everything new or updated will get all the advantages.

We can even enforce a new Wayland2 protocol, everything old can just render through XWayland as a blurry mess, Gtk3/4 included (they do support X still after all), and everything new can use the improved protocol immediately.

Just make it a required feature in Gtk4 and distros and apps will be forced to support it.

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