(I just went to check my several-years-old impressions against Darktable’s almost-undocumented config file, and... it no longer seems to have these settings? I’m not sure.)
Unfortunately, the “UI scale” thing seems to be baked into Wayland nowadays; I have no idea how to get Evince to realize that an A4 sheet at 100% should be 210 cm wide whatever my screen resolution and “UI scale”.
Modern CSS is quite close to Turing complete, so an entirely constraint-driven design (which is what's needed when more than one unit is being chosen by the user) ought to be feasible. You need at least "real world units" for stuff like the minimum size of touch targets, and "angular units" (like CSS pixels) for the general scaling of widgets. Plus it would be nice to add a separate scaling factor for text, since users differ widely in what they find most readable. So that makes for three independent settings, in the general case.
That touch targets need absolute lengths is a good point.
> So that makes for three independent settings, in the general case.
Yes, and you’ll notice that’s what Darktable does (or did) :) I’m not unsympathetic, just have never seen it done in a moderately complex situation.
> Modern CSS is quite close to Turing complete, so an entirely constraint-driven design (which is what's needed when more than one unit is being chosen by the user) ought to be feasible.
I suspect it’s not a question of theoretical expressive power so much as ergonomics: allowing easy description of (what people think about as) simple things. It probably doesn’t have to be precisely; if a full constraint-based / linear programming approach[1] is the way to go, I expect designers will adapt, it’s just that last I checked those could be quite tricky to use: small changes could lead to drastic rearrangements of the layout, and as soon as you try to add a couple of breakpoints the whole thing becomes NP-complete.
It’s like, say, LR(k) parsers. LR(k) parsers are nice, fast, and good at expressing our intuitions about ambiguity (unlike ordered choice). They are expressive enough for almost anything you might want to say. But nobody really wants to work with them, the failures are tricky and hard to predict, and they lack many things you want for modularity (say, closure under unions).
It seems to me that the situation with truly resolution-independent layouts is similar in this respect: we can technically do them, to some extent, but they are a pain, so nobody does. And it’s not so much a problem of finding the perfect language as a problem of figuring out what it is that we want to say that seems so simple in our heads.
Sure, that's a given with the constraint satisfaction approach but NP-complete problems work just fine when N is small enough.
Android is still about the only OS with reliable density independence. It's also the only one where things like DPI were an initial part of the UI system, and not something bolted on later.
Windows has been trying to retrofit density independence for nearly a decade now, and it's still pretty hit or miss. Apple didn't bother trying at all, and has been more successful at pretending it works (so scale rendering by whole numbers only, then fractionally scale the resulting image to the actual display size). Web browsers mostly went the Apple route, but we all also regularly expect pinch/zoom scaling to fix any glaring issues anyway and just accept it's kinda janky. Linux... well, Linux is still struggling with the basics of putting stuff on screen (Wayland vs. X11). I wouldn't hold my breath for that ecosystem to get this UX refinement working well anytime soon. Especially not across the many UI widget systems, window managers with differing border decorations, DEs, etc...
The problem, as usual, is getting the apps to actually use it.
(This doesn't handle multi-monitor setups well, since font size would be the same for them all. But multiple monitors were not exactly common back then.)
WM_DPICHANGED is a late addition, yes, but it's only necessary for the apps to dynamically reflow if the user changes that setting. Before it showed up, you'd have to restart the app for it to register the new value - but that does not preclude DPI independence as such.
The real problem was that almost everything in Win32 outside of CreateDialog uses device pixels to position. You were supposed to use GetDialogBaseUnits and/or MapDialogRect manually to get the correct values, and very few apps did.
For another early example, Visual Basic (VB6, pre-.NET, so we're talking 1998) measured everything in twips.
Not entirely. The font size can still be changed independently of the DPI, and not everything should be scaled as a result. Things like dividing lines and padding probably shouldn't be scaled when the font size is increased.
You still need a distinct DIP value independent of scaled font size. So the value of 'dp' vs. 'sp' in Android terms, which it looks like Windows' now also has that distinction.
And yeah this is ignoring that things like the visual winforms tool in Visual Studio really just wanted to operate in fixed positions, and just getting things to work when the window was resized wasn't always intuitive or obvious. So even if the APIs were there, the ecosystem definitely didn't care about it and Microsoft's own tools definitely didn't help.
Fixed layouts is orthogonal to all that - so long as those fixed layouts are defined in DPI-independent units, they will scale just fine. FWIW in WinForms (and also Delphi VCL, where this originated) you'd normally use anchors to design layouts that scale when the window is resized. Granted, it's nowhere near as flexible as proper layout containers - which WinForms (2.0+) also has, and which the visual form designer also supports, although it can be a pain to work with them.
Now we still would need to scale images etc, but that is much less an issue than fractional scaling text or lines etc.