3 ms·
> The size of the system font was basically a proxy for DPI. Not entirely. The font size can still be changed independently of the DPI, and not everything shou
by kllrnohj 5y ago
> The size of the system font was basically a proxy for DPI.
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.
- int_19h 5y agoIf I remember correctly, the system font size couldn't be changed independently of the DPI, at least not in a supported way. You could change it yourself on a per-window basis, but a well-behaved app is not supposed to do that. 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.