3 ms·

> I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, but changing them to support an entirely new di

> I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, but changing them to support an entirely new display server protocol with its on set of problems is ... nice, clean solution? Because if it was just setting a new property in a toolkit, we would not have this discussion now. Ultimately, it is not just that; if it were, all clients would be Wayland native already as the toolkits have had Wayland backends for years.

AshamedCaptain 6y ago
It is just setting a new property. The discussion here I thought was what is required to distinguish a client that is DPIaware versus one that it is not, for use by the compositor to decide whether to scale it transparently or not.
- vetinari 6y ago
  It's not just setting a new property. Meanwhile, today, you have clients that are dpi aware and are not setting the property. And they all will be out in the wild for an undetermined amount of time (because stuff works for the application developers, why bother?). If you do not handle them anyway, your users will complain that your desktop is broken.
  - AshamedCaptain 6y ago
    It is just setting a new property. I am not sure we're on the same page here, but if your existing client is DPI-aware, and you just want to let the compositor know it, then it is a one-line change in your client. As for the "Meanwhile" part, again, how is that better with a new display stack? Unless the point here is that it will be better to just break all those (DPI-aware) clients unconditionally, rather than actually offering them a way forward that does not involve targeting an entirely new display server API.
    - vetinari 6y ago
      Because that "meanwhile" takes years. There are still clients that use libX11 ("it works for them") instead of libxcb. libxcb was introduced in 2003. So "meanwhile" you would have apps that are not DPI aware without flag, DPI aware without flag and DPI aware with flag. And even crappier desktop as you have now for years to come. The new API is not just for DPI; it is for many reasons, DPI is only one of the issues.

AshamedCaptain 6y ago

It is just setting a new property. The discussion here I thought was what is required to distinguish a client that is DPIaware versus one that it is not, for use by the compositor to decide whether to scale it transparently or not.

vetinari 6y ago
It's not just setting a new property. Meanwhile, today, you have clients that are dpi aware and are not setting the property. And they all will be out in the wild for an undetermined amount of time (because stuff works for the application developers, why bother?). If you do not handle them anyway, your users will complain that your desktop is broken.
- AshamedCaptain 6y ago
  It is just setting a new property. I am not sure we're on the same page here, but if your existing client is DPI-aware, and you just want to let the compositor know it, then it is a one-line change in your client. As for the "Meanwhile" part, again, how is that better with a new display stack? Unless the point here is that it will be better to just break all those (DPI-aware) clients unconditionally, rather than actually offering them a way forward that does not involve targeting an entirely new display server API.
  - vetinari 6y ago
    Because that "meanwhile" takes years. There are still clients that use libX11 ("it works for them") instead of libxcb. libxcb was introduced in 2003. So "meanwhile" you would have apps that are not DPI aware without flag, DPI aware without flag and DPI aware with flag. And even crappier desktop as you have now for years to come. The new API is not just for DPI; it is for many reasons, DPI is only one of the issues.