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
> Your code works well on my PC with a 24" monitor at 1920x1080 and DPI
> manually adjusted to 144.
Forgot to add that the dpi configuration panel on windows7 works as a percent
over default, that is, to set it to 144ppi I actually chose 150% increase and
that results on 96*1.5=144
_
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.00
On 09.01.2011, at 20:22, Petter Olsen wrote:
>> That's great to hear. However, I will start with FLTK 3.0 as soon as
>> 1.3.0 is final.
>
> That's the best news I've heard in a very long time!
I'm at it. You can take a look at the currently quite messy code here:
svn co http://svn.easysw.com/p
> That's great to hear. However, I will start with FLTK 3.0 as soon as
> 1.3.0 is final.
That's the best news I've heard in a very long time!
I have developed grey hair (no pun intended, it's quite literally true) the
last year worrying about what I'm going to do with our FLTK 2 based
applicati
On 09.01.2011 18:10, nigo wrote:
The fix consists on calling SetProcessDPIAware() as soon as possible during program
initialization. It disables the "fake" dpi results and the built in
magnification so applications look sharp again and, smaller.
Thanks for the code. I tested this using the c
> It's in 1.3.0RC3: Fl::screen_dpi(float &hor, float &vert, int =
> screenIndex);
>
> I hope it helps, although I am concerned that the OS routines we use =
> seem to return 72 pretty much all the time... .
>
>
@Matthias Melcher:
No, it doesnt work on Windows Vista and above due to the built in m
On 06.01.2011, at 22:25, corvid wrote:
> Matthias wrote:
>> On 06.01.2011, at 19:03, corvid wrote:
>>> Hello all,
>>>
>>> FLTK 2 had fltk::Monitor::all().dpi_x() and ...dpi_y().
>>> What is the equivalent in 1.3? I can't seem to find anything.
>>
>> No equivalent. I'll put it in for you tough (
Here is my first try on FLTK3 trying to compile with mingw, attached is a
patch that mad it compile till fluid without including it.
En 06/01/2011 22:01:01, Matthias Melcher escribió:
FLTK3 will basically be the stable FLTK1 core with a revised interface,
more in the style of FLTK2. I am und
Matthias wrote:
> On 06.01.2011, at 19:03, corvid wrote:
> > Hello all,
> >
> > FLTK 2 had fltk::Monitor::all().dpi_x() and ...dpi_y().
> > What is the equivalent in 1.3? I can't seem to find anything.
>
> No equivalent. I'll put it in for you tough (anything to support Dillo -
> great project!),
On 06.01.2011, at 19:03, corvid wrote:
> Hello all,
>
> FLTK 2 had fltk::Monitor::all().dpi_x() and ...dpi_y().
> What is the equivalent in 1.3? I can't seem to find anything.
No equivalent. I'll put it in for you tough (anything to support Dillo - great
project!), but...
> (Dillo is trying t
Hello all,
FLTK 2 had fltk::Monitor::all().dpi_x() and ...dpi_y().
What is the equivalent in 1.3? I can't seem to find anything.
(Dillo is trying to make the transition at last)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/list
12 matches
Mail list logo
