2 ms·

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 sligh

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.

vetinari 5y ago
> 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. You can start. Show 'em.
- kuschku 5y ago
  > You can start. Show 'em. I have. 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.
  - vetinari 5y ago
    > modifying Qt and Gtk2 apps 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).
    - kuschku 5y ago
      Just make it a required feature in Gtk4 and distros and apps will be forced to support it.
      - md8z 5y ago
        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-stability-promise-in-gtk/ https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta...
        kuschku 5y ago
        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.
        md8z 5y ago
        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.
md8z 5y ago
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.
- kuschku 5y ago
  > 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.
  - md8z 5y ago
    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 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.

vetinari 5y ago

> 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. You can start. Show 'em.

kuschku 5y ago
> You can start. Show 'em. I have. 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.
- vetinari 5y ago
  > modifying Qt and Gtk2 apps 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).
  - kuschku 5y ago
    Just make it a required feature in Gtk4 and distros and apps will be forced to support it.
    - md8z 5y ago
      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-stability-promise-in-gtk/ https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta...
      - kuschku 5y ago
        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.
        md8z 5y ago
        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.

md8z 5y ago

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.

kuschku 5y ago
> 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.
- md8z 5y ago
  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 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.