> ...the above require the developers of all window managers, all desktop compositors, all widget toolkits and applications not only to coordinate with each other but also handle various cases...
/me wonders if OP has been paying attention to how "consensus building" actually ends up working in the Wayland world
> With Wayland since everything was done from scratch, there were less people that needed to be convinced to cooperate - and in practice since Wayland originated from RedHat and the GNOME ecosystem, convincing the appropriate GNOME and Gtk developers to cooperate was probably a coffee break away...
/me realizes that the answer is "No. Not really."
To be less droll:
1) Through xrandr, even windowmaker provides the data required for an application to know the properties of the monitor that > 50% of each of its windows are on. Given how much nicer xrandr was than xinerama, WMs that cared about multihead moved over to it fairly quickly.
2) I'm certain that not every WM provides the information required for screen-DPI- and screen-scaling-aware programs to scale as desired. But, the "Wayland is a lightweight protocol that makes few policy decisions" motto turns out to mean that for most decisions that users care about, each Wayland WM (or whatever the Wayland terminology for the Wayland equivalent is) needs to re-make and reimplement those decisions. Feature fragmentation has been bad. So, no, if you're not going to hold Wayland to the "Every WM must implement all the features" standard, then you're not going to demand that of Xorg WMs.
3) You happened to mention the two things that's needed for Xorg to support both HiDPI and non-integer scaling... GUI drawing library support and a common protocol for setting and retrieving user-driven adjustments to the "natural" rendering scale given the display DPI. XRandR [0] has either always, or has effectively always provided the information required for GUI toolkits to scale their widgets according to a screen's DPI. And the XSETTINGS protocol [1] is used to store the user-commanded scaling adjustment. Glancing at the release date for those two things, they either substantially predate or came out very, very shortly after Wayland's initial release.
Weird. It's almost as if we were waiting on the GUI toolkits to use what Xorg had been providing them for ages.
Anyway. Check footnote 1 in the comment you replied to for the on-the-ground details on GUI toolkit render scaling on Xorg from an end-user's perspective.
[0] adopted no later than 2007
[1] first proposed in 2001 and adopted no later than 2009 (though, if I cared to spend more than a few minutes on the search, I expect I'd find that it was adopted much earlier)
What i described was about Wayland, GNOME and Gtk specifically, not the entire "Wayland world". Wayland has been a mess that could have been completely avoided if people just tried to fix any issues with Xorg instead of falsely claiming that Xorg cannot be fixed and we'd had proper support for HiDPI, HDR, mixed refresh rate configurations with compositing and all sorts of other nice things at least a decade ago instead of creating a pointless schism in the already tiny Linux desktop ecosystem but ultimately you cannot control what other people spend their time on.
1) Window Maker does not provide anything to any application, if applications need such information they have to use the extension APIs themselves. IF there was an agreed upon protocol for window managers notifying applications to scale themselves, then Window Maker could implement it. But such a protocol does not exist.
2) Window managers do not provide any information there at all since there is no such support. And yes, all Wayland compositors do need to implement that stuff, but because it started from a clean slate and Wayland compositors had to be written from scratch anyway, it was easier to convince developers to do that because they self-selected to go through the effort of making a Wayland compositor in the first place. As i wrote in my original post, the issue here isn't if something would be written or not, but convincing the people who work on the projects. It is mainly a social issue, not a technical one.
3) Yes, without any other support in place, GUI toolkits and other applications can use the information exposed RandR to implement scaling themselves but, as i already wrote, this is a fallback solution because the rest of what i describe is not there. This is far from having robust support, ignores things like custom scaling options, handling moving windows between desktops and support for applications that do not do scaling themselves (which is many of them), among other things.
All of the above are things i already addressed in my original message BTW and again, the issue is not technical but social/political. It is about convincing people to cooperate, not if something is technically possible (and let's be honest, it isn't like Xorg's code is written in stone, if something is currently impossible, the code could be extended to make it possible).
/me wonders if OP has been paying attention to how "consensus building" actually ends up working in the Wayland world
> With Wayland since everything was done from scratch, there were less people that needed to be convinced to cooperate - and in practice since Wayland originated from RedHat and the GNOME ecosystem, convincing the appropriate GNOME and Gtk developers to cooperate was probably a coffee break away...
/me realizes that the answer is "No. Not really."
To be less droll:
1) Through xrandr, even windowmaker provides the data required for an application to know the properties of the monitor that > 50% of each of its windows are on. Given how much nicer xrandr was than xinerama, WMs that cared about multihead moved over to it fairly quickly.
2) I'm certain that not every WM provides the information required for screen-DPI- and screen-scaling-aware programs to scale as desired. But, the "Wayland is a lightweight protocol that makes few policy decisions" motto turns out to mean that for most decisions that users care about, each Wayland WM (or whatever the Wayland terminology for the Wayland equivalent is) needs to re-make and reimplement those decisions. Feature fragmentation has been bad. So, no, if you're not going to hold Wayland to the "Every WM must implement all the features" standard, then you're not going to demand that of Xorg WMs.
3) You happened to mention the two things that's needed for Xorg to support both HiDPI and non-integer scaling... GUI drawing library support and a common protocol for setting and retrieving user-driven adjustments to the "natural" rendering scale given the display DPI. XRandR [0] has either always, or has effectively always provided the information required for GUI toolkits to scale their widgets according to a screen's DPI. And the XSETTINGS protocol [1] is used to store the user-commanded scaling adjustment. Glancing at the release date for those two things, they either substantially predate or came out very, very shortly after Wayland's initial release.
Weird. It's almost as if we were waiting on the GUI toolkits to use what Xorg had been providing them for ages.
Anyway. Check footnote 1 in the comment you replied to for the on-the-ground details on GUI toolkit render scaling on Xorg from an end-user's perspective.
[0] adopted no later than 2007
[1] first proposed in 2001 and adopted no later than 2009 (though, if I cared to spend more than a few minutes on the search, I expect I'd find that it was adopted much earlier)