I have practical case with Haiku USB installation that run in PC and tablet. Tablet have higher DPI and I currently need to adjust a lot of settings to change DPI.
I should be able to set DPI for specific monitor and it will be automatically used if monitor with the same ID is used. Connect USB disk to PC – get small UI, connect to tablet, get bigger UI.
You have not demonstrated any advantage of doing that over the current way, It is not a hack but merely a linear scale that can be used. Since the original value is known a non-linear scale can be used if one wants.
DPI is a constant for each monitor, it is not a user setting, and for the most part we do not care that much about the DPi but rather about the actual size the user wants, this is a preference and not something we can querry for.
Monitors already have different DPI values, I see no problem with font sizes per monitor, we aren’t forced to implement multi monitor like in windows.
I already said that font size have no clear meaning. Font size value can be very different for different font files with actually same size letters. Depending on font size can cause broken layout. You can compare Noto and DejaVu fonts for example.
We have a number N and a default of 12, and we scale based on that. Is your argument that users can install broken fonts? I don’t think the layout kit has to care about this eventually
No, he’s not. He is suggesting at having a scaling factor, and then render everything scaled by this factor. So if you have a font size set of 12 pt and a scaling factor of 1.5 you render it at 18 pt instead. And if a UI element renders at 12px width you render it at 18px width directly. That’s how it also works on other systems. There is no quality loss with this.
As I understand it the only difference is that the proposal is to have an explicit scaling factor that can be set based in the monitor, while the current implementation uses an implicit scaling factor that is calculated by the set font size in relation to a reference font size.
An implementation based on such scaling factors potentially can also support multiple monitors with different DPI settings. I don’t know how this should work with the current idea of using the font size. Once Haiku gains proper multi monitor support this problem will for sure come up.
What you are confusing probably is that on other systems also allow scaling up applications which have a rendering system that does not allow such scaling. E.g. the UI is completely bitmap based. That’s a compatibility thing for old software, and it is something that Haiku would probably need to support as well.
Font 1 with “size 12” can have actually significantly different size than font 2 with “size 12”. I may want to set different font size to compensate this but I don’t want to get other GUI elements scaled.
12pt fonts have a set size, they are always 12pt high, this is a unit of measurement
The current implementation scales UI elements based on where it makes sense to do so, text labels and such are “automatically” scaled based on the font size, since it is aet bigger. Other elements are scaled in tandom with this. If you add a scale factor ontop of this you would actually get fonts that are much bigger unless you choose to ignore text labels, but that seems much harder to implement to me. With the current way we can decide for elements whether a linear scale makes sense or doesn’t.
To me Noto fonts are broken, it cause large empty space around text and makes GUI elements bigger. With font based scaling it become even more broken.
The font should render the same for the height (the claimed height, not neccesarily how high chars appear, that is up to the font, but the allocated space is not), the only difference can be white space that is introduced in text labels (around text) and dependant UI elements. The scaling code for the rest is identical, so this wouldn’t even be fixed with your proposed API.
Noto has “Noto Sans Display” as a more condensed variant.
In any case font is user preference, for me It looks and works fine, I don’t see a problem there.
Independent font and scaling setting give more flexibility. I may want to set different font size but not scale GUI elements.
Nobody suggested to add another scaling on-top of the current font-based scaling. The font-based scaling should be replaced by a factor based scaling. Font-based scaling is broken by design.
You didn’t quite understand me:
If a user sets 18pt font size they now get 18pt with additionally the rest if the Ui scaled up apropriately.
If we remove this scaling but add a scaling like 1,5x ontop they will now get 27pt fonts with the other elements the same size as before, unless we have complex code to figure out which elements are dependant on the font size and which aren’t. some elements hold glyphs as only elements and set their size constraints based on that.
Also: nobody in this threat has demonstrated that “Font based-scaling is broken by design”.
I think this gives more flexibility because we can scale the elements that make sense and not scale those that do not make sense to scale, or scale them differently based on what makes most sense.
How do I scale up the font to 18 pt without scaling the rest of the UI?
Except that it does not work well, requires multiple settings and hacks in code, plus there are (and will be) lots of unscaled UI elements. Let’s stop with the “we do it better” elitism/delusion and follow suit with rest of the other operating systems that does it right. Currently it’s a lame hack that takes advantage of the some responsive UI elements that Haiku has, nothing more.
I don’t understand why you keep such a tone honestly, I take an effort to try and present my viewpoint based on argument and try to discuss based on the actual implementation.
Haiku isn’t perfect, neither is the code, thus we have discussions.
I don’t apreciate beeing called delusional or elitist for volunteering my free time to discuss issues with other developers. And even less so if you claim without evidence that it “requires multiple settings and hack in code” and then go on to basically asserting that we should just throw away all work we do and just copy whatever microsoft or linux does, without discussing what they are actually doing, and why their aproach works or doesn’t, and what we could learn or not.
You still not give an example what elements makes sense to scale and what are not. For monitors like Apple Retina all elements makes sense to scale otherwise it will be almost invisible.
To quote you again a few messages above I’m glad that you changed your mind and you are open to discussion in against to what you’ve stated here.
Since you seem knowledgeable about text rendering, and claim that for Haiku it is better than the others, I’d assume that you have an idea about what other systems do. If not, I’d suggest having a look at their documentation and various articles about how their rendering works. Then I’d recommend you list your findings, and how it compares with Haiku.
What evidence do you need? Go to Appearance settings and set three font sizes. If you want nice Terminal rendering add that as well. Code hacks have been mentioned above as well, please read carefully.
I didn’t change my mind, Your message above illustrates exactly why I thought it was pointless to bring it up, especially in a topic where a user solely asked for some pointers.
And I’d recomend you don’t tell me what to do, the status qou is fine, I am happy to discuss it, but not happy to strawman others arguments, and even less happy that you are trying to claim something that you have no evidence for and then try to lay the burden of proof on me.
As for text rendering: We use freetype2… same as almost everyone else, how does that make us better?
You claim that setting font sizes is too complicated, and then assert that the solution is to add even more options, that makes little sense to me. I can read just fine, thanks. You might also have read that I disagree with the assertion that the code is a hack. Or that the concern with Terminal has been discussed above aswell.
Anyway, I don’t like this climate you are producing. So I will simply leave this discussion after answering X512’s querry.
I agree that it makes sense to scale all elements at such huge sizes, But i don’t think they should be scaled the same way.
For example: Tab buttons in webpositive are scaled by the font size for such big displays.
Some elements should be solved by layout constarints instead of rigid scales: scroll bar thumb, spacing of elements in 2*N groups.
And some elements make sense to always have a 16 * N pixel width like desktop icons, I don’t think you can easily do this with the proposed scale.
We can also make some elements bigger than rigid scale on high resolution displays If we use a not so good way for lower resolution displays to indicate something, for example the splitter could be made bigger with a different graphical cue. Though there are probably not too many options for this.
nephele: Please answer my question beow.
It can be still easily done: size = round(iconSize * scale / 16) * 16.