In other words: Haiku isn’t about having “all the options, all the time”. We aren’t Linux (or even the BSDs), though we also aren’t nearly as “opinionated” as Apple. If the option makes sense to have, then we’ll have it. But if it has a usecase so niche that only a small number of “power users” will ever have reason to change it, then we’ll probably leave it out.
(I have a hazy recollection of some quippy remark, perhaps from @axeld, used as a litmus test for whether options should be presented to users or not, but I can’t seem to remember it fully, and a quick search isn’t pulling it up.)
You can get this result by reading the raw glyph outlines from a font, scaling them down to desired size and render them as they are, basically without executing a single instruction of the font program. If we wanted that, we wouldn’t even need the freetype renderer, we wouldn’t even need actual fonts, just outline data. We would spare so much space! It would in fact require less resources to not run the font program (and/or autohinting) than to run it. But there is a good reason we do not do things that way. Your result is not perfectly illegible in that relatively large size (how does 2% look like?), but try and comare it to the same text rendered properly at the equivalent pt size. And I just don’t think this “hack” with fonts is a solution to the original problem anyway.
I don’t think there are sensible defaults that work on both a 4K TV screen, a 4K phone screen, a 14" VGA notebook display, and the pletora of other display devices. Do you think the current default of 2 mm text on a big HDPI screen is sensible? I suggested that aiming for the same number of visible text lines on any display would make a more reasonable default, than a fixed font size, but according to PulkoMandy, we do not want that. So what do you think would work as a good default for everybody?
The defaults are currently set based on the display resolution. Above 1080p and up to 4K, we’ll use 1.5x the default (so “18”), and above 4K we use 2x (so “24”). Ideally we’d get the screen DPI and use that to set a default, yes, but as PulkoMandy noted we can’t always retrieve that information reliably.
Hmm, I didn’t know that. I wonder why the bands (1x, 1.5x, etc) instead of near-linear scaling.
Why do you think the display DPI should be considred in any way? It would resolve what problem? I definitely don’t want the text to have the same physical size through different displays, I want it to be proportional to the display size. We only need to know the resolution (pixel count) for that. The DPI could perhaps serve as a limit so that a minimal physical size is maintained all the time regardless of pixel density. I’m not sure if that’s necessary or desirable, though.
Display size is determined by physical dimensions, not by pixels count. You can have 2880x1900 resolution, but that information gives you no info how big the display is, it can be 15", 27" or anything in between. That’s why you need to read the physical dimensions from the display’s EDID. The PPI/DPI value is calculated from that as a convenient way to determine the font size multiply factor. The end result would be close to your suggestion of having the same number of visible text lines on any screen, just with some threshold values (it can also be made a linear dependence, it’s more about having a consensus on what strategy is better for setting the default font size).
That sounds like some mathematical overcomplication. The DPI or physical display size is one hundred per cent irrelevant if we just want the same proportions. How do you draw 50 horizontal bars to any screen? You take the display’s vertical resolution (screen-height in pixels), divide that by 50 and draw the bars of that height (of so many pixels). You don’t need to know how big the display physically is. If you draw a 108 px tall box on my phone’s 5" FHD screen (~350 DPI) and the same 108 px tall box on my TV’s 50" FHD screen (~35 DPI), they will both show up as 1/10 of the display height. Who cares if it’s 10 times as big physically on the TV than is on the phone? The screen itself is also 10 times bigger, so the proportions remain the same.
It is not possible to keep a list of every such devices. For example, let’s consider projectors. The physical size of the projected image, and hence the DPI, changes by how far you place the projector from the canvas/wall. Not only it will never be reported (correctly), it is even impossible to list the correct values because there are simply no correct values.
There are various ones, I can remember the one about the font cache size setting that beos had: “did you ever change it? Did that ma%e you feel good?”
I should note that this was several years before Marie Kondo said pretty much the same things about removing useless things from your life and environment
Wait, so you want to have the same amount of text lines not only for the same screen sizes but across all the screens? If so, I don’t think you’ll find many supporters of that idea here. When I connect my 32" display I definitely want to see on it more text lines in the code editor than I see on my 14" MacBook. What’s the point of using it otherwise?
Yes, but that’s not the goal. For example, Haiku doesn’t have drivers for every graphics adapter out there, and it won’t ever have them all. But it doesn’t mean we should discard the idea of providing better UX for the users whose graphics cards we have drivers for.
Yes, because that would make a sensible default, imo, and then you could customize that (via the propesed UI size preference) according to what purpose you plan to use the display. Neither physical size nor screen resolution or the derived DPI tell much about that, only the user can provide that info to the system.
Doesn’t make much sense to me to go through all that effort just to let users customize it again. We end up in the same situation as we are now, and the N lines per display is pointless. You will always find displays this is a terrible choice for.
Why bother implementing such a convoluted system? The current one works just fine.
We take an educated guess about the display and users can adjust this. Much better than some random scaling.
It is a matter of personal preference, but my personal opinion is that the current defaults work out well with 800x600 resolution (or the wide screen equivalent) and that’s it. 1024x768 is borderline okay/acceptable. Controls take up too much space at any resolution lower than that, and they’re increasingly harder to use (because of their tiny size in relation to the whole desktop) at higher resolutions.
800x600 is our minimum supported resolution. And to support anything lower we need to change layouts of apps (like locale preferences), not the control spacing.
I sure hope no one plans to change that. Haiku on 1080p displays is amazing precisely because it is the only modern OS where I can make good use of all these pixels and have 2, 3, 4 or more windows visible at the same time. Please don’t add a lot of empty space just to make things easier to point at.
That’s just the math I do in my head: “I would like the fonts to be twice as big as the default one, so it’s 12x2 (24), and in the VM I’d like it to be 150% of the original one, so it’s 12x1.5 (18)”.
But honestly, I’d be happy if we name it anything else (e.g. “Regular - Bigger - Large - Huge”), or simply make it a slider with font size values (“12 - 14 - 16 - 18 - 24” or “12 - 13 - 14 - 15 - …”). As long as we keep just one control by default instead of the four we currently have. Currently it’s very annoying to adjust 4 numbers when switching between screens and environments (bare metal <> VM run from the same partition). How often do people need to change font sizes to different values? I bet that not many of those people will complain if they’d need to click the “Advanced…” button or tab to be able to do it.
The casual expectation for 200% scaling is that, if using a 16:9 4k screen would display as a 16:9 fullHD screen would.
But for out font scaling metrics that will never be the case, this is because some stuff is already scaled non-linearly, and we likely will have more in the future. For example having “steps” in scaling for where this makes sense, allowing the decorator to control sizes of metrics is yet another thing.
In any case, sure we can make the ui of appearence a bit more pleasing.
Check out the UI of WebPositives settings, those are already one step in that direction. Maybe now have a slider instead of the spinnerbox (and potentiall “configure individually” combobox and otherwise use the upper slider for all)
