On 09.01.2011 21:30, nigo wrote:
> Your code works well on my PC with a 24" monitor at 1920x1080 and DPI
> manually adjusted to 144. Here is the output of both codepaths:
>
> D:\home\dpi>test
> set_show_dpi(81): size=14, scrollbar_size=16
> set_show_dpi(95): size=14, scrollbar_size=16
> Screen 0 ( 0, 0,1280, 695) res. is 96.000 x 96.000 ppi
>
> D:\home\dpi>test 1
> set_show_dpi(81): size=14, scrollbar_size=16
> set_dpi_aware() returned: 1
> init_theme(57): size=-18
> init_theme(74): size=18, scrollbar_size=26
> set_show_dpi(95): size=18, scrollbar_size=26
> Screen 0 ( 0, 0,1920,1042) res. is 144.000 x 144.000 ppi
>
>
>> Thanks for the code. I tested this using the code you provided, but the
>> result is the same for me (Windows 7, correct dpi value about 89-90,
>> result 96). That's the same as without calling SetProcessDPIAware.
>
> Have *YOU* actually changed your dpi on the screen properties panel? If you
> havent, then there is nothing to adjust for and the results will be the same.
> I dont think Win7 is polling EDID info from the monitor and adjusting
> automatically.
No, I had not changed it. I found out myself looking aroung how to do it
and found it. With adjustment (120%) I get:
$ ./tabs
set_show_dpi(84): size=14, scrollbar_size=16
set_show_dpi(98): size=14, scrollbar_size=16
Screen 0 (1402, 0,1403, 877) res. is 96.000 x 96.000 ppi
Screen 1 ( 0, 0,1402, 838) res. is 96.000 x 96.000 ppi
$ ./tabs xxx
set_show_dpi(84): size=14, scrollbar_size=16
set_dpi_aware() returned: 1
init_theme(60): size=-14
init_theme(77): size=14, scrollbar_size=20
set_show_dpi(98): size=14, scrollbar_size=20
Screen 0 (1680, 0,1680,1050) res. is 115.000 x 115.000 ppi
Screen 1 ( 0, 0,1680,1004) res. is 115.000 x 115.000 ppi
>> Why are you using lfMenuFont ? Isn't the menu font always smaller than
>> normal (text) fonts? What would be a better font?
>
> On Windows XP it worked better using the menus than the dialog or normal text
> font since WinXP dpi handling is broken. I guess you could poll all of them
> and get the highest, but definitely NOT the average as you will usually get a
> lot of unchanged stock font sizes and only one changed to actual useful size.
In the default setup, all fontsizes I tested (meanwhile) were the same.
I didn't test different with adjusted magnification.
> It seems my heuristic (menu size) is failing on your configuration.
I see.
> Your results for scrollbar width seem ok, since fltk has always used
> scrollbars that are too thin for windows standards.
Yes, with adjustment I get bigger scrollbars.
> By the way, you should NOT condition the call to init_theme to the success of
> SetDPIAware() since you still want your apps to adapt to user dpi
> configuration on winXP.
Thanks, my code was just a quick hack for testing, not for final
production code.
> Most users never touched it in the past, but as users get higher resolution
> monitors the text starts to look too small to read comfortablyand they begin
> to adjust it. The informed ones, that is. Many just run their LCDs in a lower
> resolution mode to solve the size problem.
>
>
> On a different note, I provided the init_theme function for you to play with,
> not to directly include into fltk codebase to fix dpi since it will break
> existing apps looks. Widgets are placed using fixed positions and sizes and
> bigger font sizes will make the text overflow and labels wont line up
> properly as compared to fluid.
Yes, that's clear, but it was a great help for testing.
I do even think that we should not include the dpi_aware setting
unconditionally in FLTK. It should be a user option, or maybe a
function that can be called just at the start of main().
>
> I usually create my widgets using multiples of FL_NORMAL_SIZE with the
> following heuristic, that seems to be good enough for the general case:
>
> widget_width = (FL_NORMAL_SIZE+2) * desired_text_columns;
> widget_height = ( desired_text_rows * FL_NORMAL_SIZE * 45 )/ 100;
> // char width = 45% height
Nice.
> FLTK needs a layout system, but you already know it :)
Yes, I know people ask for it. ;-)
My app scales and resizes all fonts dynamically, and we use
server-generated ("hand-made") forms, so that I personally don't
need such a thing. However, we use group-relative coordinates
that are transformed internally, and that makes life much easier.
But FLTK 3 is coming... ;-)
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
