GTK2 had an integer DPI variable. GTK3 now just has an integer scale variable.
GTK2 could actually render at 144dpi, or 108dpi, just fine. Everything was slightly misaligned, not everything scaled perfectly, but it worked.
X11 had an integer Xft.dpi variable. Wayland now just has an integer scale variable.
WHY was this downgrade made? If a protocol break could be made to remove this functionality, a protocol break to add it back should be just as justified.
Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well.
Yes, I am extremely angry after having spent years yelling at the wayland-wg and gnome devs not to make these decisions, not to put these things into the protocol, and complaining that if an API break is necessary, it should be extensible for these use cases. I’ve been complaining for a decade now and all of the complaints got ignored and instead the mistakes I warned about were made.
That DPI value AFAIK only changed the text scale, not the scale of widgets. You are thinking of two different things, the GTK3 integer scale actually affects widgets. The Xft.dpi setting also originally only meant text scale but has apparently been overloaded to apply to widgets in Qt? I'm not sure, I haven't tried this recently and I don't use X11. But it's right there in the name: Xft is the X freetype font rendering.
I understand your frustration but from what I have seen, nothing has actually been removed. This is just a feature that was never implemented because nobody signed up to implement it. Wayland could be extended to support it eventually but somebody actually has to put in the work. I think the best bet for somebody working on this would be to get it fully working and stable in KDE first, since Qt apparently has the toolkit support for it, and then maybe it can be adapted to work for GTK.
> I understand your frustration but from what I have seen, nothing has actually been removed. This is just a feature that was never implemented because nobody signed up to implement it. Wayland could be extended to support it eventually but somebody actually has to put in the work. I think the best bet for somebody working on this would be to get it fully working and stable in KDE first, since Qt apparently has the toolkit support for it, and then maybe it can be adapted to work for GTK.
The issue with that is that first of all, the wayland protocol needs to be modified to add support for this, and the entire freedesktop/gnome community refuses to even consider adding support for anything like this because gnome doesn’t need it/can’t support it.
I’ve talked with vendors of devices using Linux with Wayland, who’ve been trying to get the committee to add support for years.
I’ve talked with KDE devs who’ve been frustrated without limits.
There’s a lot of people who are absolutely burnt out and angered by the constant stonewalling from Gnome, pretending for a decade that no one needs this and so it shouldn’t even exist.
I really have no idea what you're talking about or what committee you're referring to. KDE can develop its own Wayland extensions and already has a lot of them. They don't need GNOME's approval. I believe they are housed in this git repository. https://invent.kde.org/libraries/plasma-wayland-protocols
Once they become stabilized and if other desktops took an interest, then they could be proposed as standard. But KDE does not need to wait for GNOME to implement a feature in Wayland, or vice versa. If you could mention which KDE developer you were talking to then maybe we could help them get this implemented in KDE first? Then afterwards if they can offer some tips to offer GTK (or other toolkits) on how to implement this, that would be valuable to everyone.
Honestly, you're right. I should just stop trying to discuss with the wayland wg and gnome devs and just create my own protocol extension without asking anyone, submit patches to Qt, Kwin, and certain webbrowsers, and then just use those myself.
Sure, Gnome still won't adopt them ever because they're stubborn and think they know everything better, but at least I'd have a somewhat working solution.
Maybe elementary OS would actually use it too, they've already got support for just scaling everything based on the font size.
Thing is, I need this functionality yesterday. And it's been an absolute pain hearing that even if you spend an excessive amount of work today, in a community where all of gnome is against you, maybe someday in a decade it'll get better.
I think that sounds like a great idea. But I just don't understand why you were so invested in GNOME adopting them when it seems clear that they weren't really that interested, and now it seems like it actually doesn't even matter to you? I'm sure you know not to "put all your eggs in one basket" as it were.
Honestly, the big issue is that Gtk is used as basis to obtain the scaling factors for all browsers, Java, and several other tools including everything based on electron.
As long as Gtk refuses to support this, I can fix KDE, but I can't fix Java or browsers.
Java, Firefox and Chrome reject patches, saying Gnome is responsible. Gnome says they don't care.
And I don't want to run custom builds of Firefox and Java anymore. It was such a hassle constantly building them from source with my old patchset.
I think if KDE actually had a working implementation of this then that would go a really long way towards convincing those other things to support it. IIRC Chrome at least doesn't get the scale from GTK. But KDE's Wayland implementation is still unstable (in part because it seems to have a lot more features than GNOME's wayland implementation) so I think it will be a while before that happens too.
If you are really committed to using Linux and don't want to wait then I said it before but I think a better use of your time would be to spend a few hundred dollars on some different monitors that can work at just 2x scale, and then let someone else deal with this.
Ah okay. I think the work required to get this implemented across the stack will still cost a lot more than $11,000, just saying. Also in my opinion 4K monitors at that size are an unfortunate purchase because the PPI is not high enough to look crisp at that viewing distance. Apple upgraded theirs because you need to get above 200 PPI range in order to have it look comparable to print. For me personally, I couldn't justify spending my spare time working on that when other monitors exist that don't have that problem.
4K at 27" is an unfortunate resolution / density. I know, I also have such monitor :(.
That said, 10-15 fps on X11 is a pathological case, something is wrong there. When I ran X11 and played with xrandr, the slightly larger framebuffer had zero impact (outside games) on AMD Vega64.
> GTK2 could actually render at 144dpi, or 108dpi, just fine.
Your definition for just fine must differ from everyone's else. Most GTK2 shipped assets for 96 dpi and that's it. Just try running GIMP on 192 dpi display, with "properly set dpi", for example. You will see yourself that is was not just fine.
> WHY was this downgrade made?
Because it didn't work. That's why.
> If a protocol break could be made to remove this functionality
It wasn't protocol break. It was apps either ignoring the facilities (in better case) or being outright broken -> desktop locking on constant values, where everyone was able to test their wares.
> protocol break to add it back should be just as justified.
Not going to happen.
> Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well.
I’ve made a custom build from source of my entire desktop environment, changing the scale factor back to a dpi value, and modifying Qt and Gtk2 apps to use that.
And it works.
You just need to break the wayland protocol and rebuild everything from source, but for over 2 years, I ran that as daily driver setup because I was so pissed off by this decision.
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.
Oh, and with staged updates too -- it might take some 2 years to adopt your solution, if everyone cooperates (which is a big if); not all distros update at the same time and some do not bother updating for another cycle (see Ubuntu and Wayland).
> 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.
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.
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.
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...
GTK2 could actually render at 144dpi, or 108dpi, just fine. Everything was slightly misaligned, not everything scaled perfectly, but it worked.
X11 had an integer Xft.dpi variable. Wayland now just has an integer scale variable.
WHY was this downgrade made? If a protocol break could be made to remove this functionality, a protocol break to add it back should be just as justified.
Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well.
Yes, I am extremely angry after having spent years yelling at the wayland-wg and gnome devs not to make these decisions, not to put these things into the protocol, and complaining that if an API break is necessary, it should be extensible for these use cases. I’ve been complaining for a decade now and all of the complaints got ignored and instead the mistakes I warned about were made.