On 14.04.2012, at 14:47, Domingo Alvarez Duarte wrote: > I thought about this problem a while ago and came to the conclusion that > there is two issues instead of one: > > 1 - Widget resizing. > 2 - Widget Scaling. > > They are not the same, let's explain: > We have an FLTK application with resizable internal widgets and we want > to execute it on a big screen with high defininition probably will want > to SCALE the window to have a good font sizes first and then on resize it > as usual to make a better use of the total availlable space. > > We don't need to remember the original sizes at widget level, a better > place is at group level like it is now and add the font sizes to this > structure (look at this thread > http://www.fltk.org/newsgroups.php?s1+gfltk.development+v5+T0+Qst_widget_sizes). > > My propose is to have something like this. > > When resizing a window with mouse or keyboard if CTRL (or SHIFT or both) > is pressed then the operation to perform is SCALE otherwise the normal > RESIZE. > > If we want to remember the last window state we should save the scale > factor.
Ah, that sounds reasonable. In resizing, the Group maintains a list of all the original coordinates of the children, which is why the values never drift. The same must be done for all widget coordinates if we want to allow interactive scaling. But in real life, do we need interactive scaling? Wouldn't it be enough to scale the app by some fixed value at widget creation time and be done? If needed, the user can set a new scale value in some registry and relaunch the app. From then on, the app will always scale on that particular machine. We have a mechanism for storing that on a mchine/app level already called "options". There is another way that may be more difficult, but also more consistent: we have a driver model for graphics calls. Assuming we have a driver model for window manager calls as well, we could scale at driver level. The app would appear completely "normal" at API level (all coordinates are unscaled), but render in the desired size on screen. That way, line drawings and pixel images would be scaled at the lowest level without any interference form the app developer. I am not sure about the looks of scaled bitmaps graphics and AA'd lines at higher non-integer scales, but at least the fonts and box types could be verified and look perfect. - Matthias _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
