5 ms·

I've been wondering about this for a while. Why do we need scale numbers and can't use dpi? Essentially if wayland (or desktops shells) would specify sizes in a

I've been wondering about this for a while. Why do we need scale numbers and can't use dpi? Essentially if wayland (or desktops shells) would specify sizes in a "real world unit" changing the size of windows, text etc would just mean changing the dpi. In particular it would be trivial to have different size/resolution monitors display the elements at the same size. Considering if elemtents are vector graphics we don't even need fractional scaling for desktop elements. Now we still would need to scale images etc, but that is much less an issue than fractional scaling text or lines etc.

mananaysiempre 5y ago
The only program I’ve seen do it “properly” is Darktable, which has a dots-per-inch setting for things which have to be compatible with real-world linear measurements (WYSIWYG stuff for the most part), a dots-per-degree setting for things which depend on how far away you are sitting from your screen (UI element size), and a font size. I suspect the reason people don’t regularly do this is the same as the reason CSS no longer has pixels: it’s difficult to design (in the declarative CSS model) with more than one independent length unit. (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”.
- zozbot234 5y ago
  > it’s difficult to design (in the declarative CSS model) with more than one independent length unit. 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.
  - mananaysiempre 5y ago
    > You need at least "real world units" for stuff like the minimum size of touch targets [...]. 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. [1] https://gss.github.io/guides/ccss https://gss.github.io/guides/ccss
    - zozbot234 5y ago
      > and as soon as you try to add a couple of breakpoints the whole thing becomes NP-complete. Sure, that's a given with the constraint satisfaction approach but NP-complete problems work just fine when N is small enough.
kllrnohj 5y ago
It's incredibly hard to change course if the UI toolkits weren't designed for it in the first place. 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...
- int_19h 5y ago
  Windows has had the necessary bits for DPI independence since the 90s - it's why stuff like "dialog units" is a thing. The problem, as usual, is getting the apps to actually use it.
  - kllrnohj 5y ago
    "dialog units" seems to be about the size of the system font, not about DPI independence. Things like WM_DPICHANGED seem to only really show up in Windows 8+, with some stuff like LOGPIXELSX showing up as "early" as Windows 2000 but doesn't look very complete.
    - int_19h 5y ago
      The size of the system font was basically a proxy for DPI. If you set scale to higher than 100% in, say, Win2K, it would also increase that size. (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.

mananaysiempre 5y ago

The only program I’ve seen do it “properly” is Darktable, which has a dots-per-inch setting for things which have to be compatible with real-world linear measurements (WYSIWYG stuff for the most part), a dots-per-degree setting for things which depend on how far away you are sitting from your screen (UI element size), and a font size. I suspect the reason people don’t regularly do this is the same as the reason CSS no longer has pixels: it’s difficult to design (in the declarative CSS model) with more than one independent length unit. (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”.

zozbot234 5y ago
> it’s difficult to design (in the declarative CSS model) with more than one independent length unit. 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.
- mananaysiempre 5y ago
  > You need at least "real world units" for stuff like the minimum size of touch targets [...]. 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. [1] https://gss.github.io/guides/ccss https://gss.github.io/guides/ccss
  - zozbot234 5y ago
    > and as soon as you try to add a couple of breakpoints the whole thing becomes NP-complete. Sure, that's a given with the constraint satisfaction approach but NP-complete problems work just fine when N is small enough.

kllrnohj 5y ago

It's incredibly hard to change course if the UI toolkits weren't designed for it in the first place. 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...

int_19h 5y ago
Windows has had the necessary bits for DPI independence since the 90s - it's why stuff like "dialog units" is a thing. The problem, as usual, is getting the apps to actually use it.
- kllrnohj 5y ago
  "dialog units" seems to be about the size of the system font, not about DPI independence. Things like WM_DPICHANGED seem to only really show up in Windows 8+, with some stuff like LOGPIXELSX showing up as "early" as Windows 2000 but doesn't look very complete.
  - int_19h 5y ago
    The size of the system font was basically a proxy for DPI. If you set scale to higher than 100% in, say, Win2K, it would also increase that size. (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.