Domingo Alvarez Duarte schrieb: > 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).
I need to see a working example to believe this. > My propose is to have something like this. Maybe I should mention, that I don't talk about "ideas" or "things that might work", but I started with a ready made framework, which handles "scaling" (resizing not only window, but also fonts), choice of fonts type and basic size, saving and restoring window position and size and a whole subsytem, which provides a comfortable method of "live" translation and general administration of strings inside a software. I'm experienced in this, now it works since 2003. I wanted to simplify it, make it more reusable and publish it, but anyway monday the next application using it, will be delivered. But the most reusable solution would be an integration to FLTK. I also want to tell, that there is a lot of details, I didn't mention yet, but anyway I would prefer to mention them by code. So what do experienced FLTK developers think of the ways to solve 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. That's okay, but the user interface is a final step, not the basic problem. _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk