On May 1, 2007, at 3:03 PM, Michael Sweet wrote: > matthiasm wrote: >> ... >> There would be a lot of changes in the source code... . > > FWIW, this is why Apple is big on getting developers to support > resolution-independent user interfaces - they can then increase the > display resolution (DPI) without affecting the size of the controls. > > IMHO, if we add support to FLTK for this (and I think we should), then > we should base the scaling on the display DPI (available on all > platforms) and apply it such that the app still deals with pixels > at some standard resolution (96 DPI seems to be what Windows works > with) and the core drawing code does the necessary scaling > automatically. > > The only issue with this approach is that it pretty much requires that > you use images for the button backgrounds, or have some way for the > box functions to use the unscaled coordinates...
Yes, I would give access to unscaled coordinates for the box drawing functions in order to not mess with the style. But we are getting to a point where we might need floating point coordinates for text and drawings. Well, I will give this a try as soon as I manage to fix the remaining STR's and then find even more time. ---- http://robowerk.com/ _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
