According to the current code and screenshots, it is being used as pixels. Haven't you read SoFont class documentation? Do you see the "px" next to the "Sketcher - Sketch editing - Font size" number input?Elyas wrote: ↑Wed Sep 16, 2020 8:38 pmThe bug is:Before your change the default font size for EditSketcherFontSize was 17 pixels. After your change the default font size is 12 pixels multiplied by the dpi scale factor. So, before it was 17 hardware pixels, after it is 12 device independent pixels.
If in Prefereces editSktcherFontSize = 17 (px - is it means pixels?)
Unfortunately, settings don't have units enforcement. So it's hard to detect when they are not properly used in code.
According to your screenshots, you set it to 25px. 17px is a default value. 25px is 18.75pt. But since you probably have HiDPI scaling enabled, that is factored by some constant (from 100% to 400%).
Coin font size is in pixels for 2D text (a SoText2 node).
Well, when we speak of pixels, you have to specify whether those are device independent pixels or absolute pixels. Points are better because those are not ambiguous and related to inches on the screen or paper. While pixel meaning can change depending on the DPI scale factor.
It seems your solution is a hack: it works for your font settings / screen size / resolution / dpi scale ratio but you can't explain how and can't guarantee it would work for all users. Did you match it by eye? Or you can provide a formula to demonstrate that "editSketcherFontSize" is properly scaled to accommodate for HiDPI ratio?
Yes, specifying all font sizes in points and getting rid of any pixel settings should be the end goal for a proper HiDPI support.
On the wiki I provided a clear path to that state. All sizes in pixels should be either scaled by dpi ratio or calculated from the text size. All font sizes should be in points. If you need the font size in pixels, that should be calculated by taking into account the dpi ratio. If you need the font size to change dynamically when changing the window/elements size, that's a separate feature completely independent from HiDPI support.
Ideally, there should be only one setting - "base font size". And all the other font sizes should be specified in relative units - rems or ems. But probably it would be easier to implement in the browser-based UI.
True, there's no separate setting to specify a font size for the cube. But there is a global setting to scale all the font sizes up or down. It is called "dpi scale ratio" and is available in the OS display settings. Qt supports this setting automatically, so developer doesn't have to do anything.Elyas wrote: ↑Wed Sep 16, 2020 8:38 pmNaviCube:
Neither before nor after the corrections the user has any control over the font size. There is no conflict. If you want to automatically scale the NaviCube dimensions, it is possible, but that is a different task. Matching the font size and cube should still be. Now it is being done wrong.
But Coin, unfortunately, doesn't support this. So the dpi scale ratio should be taken into account separately.
As I see from you code, you just changed some magic constant which I suppose was chosen arbitrarily. It doesn't seem to support HiDPI font scaling. So users with HiDPI will need to increase the cube size, while users with small resolution displays will need to decrease the cube size. This is a bad user experience. The default size should work nicely without any fiddling with settings for users with normal eye sight and an appropriate DPI ratio..