On 10.12.2011 16:26, Bill Spitzak wrote: > On 12/10/2011 06:08 AM, Albrecht Schlosser wrote: > >> But there is a *massive* problem, if widgets are allowed to resize >> themselves in the draw() method, as it is now in FLTK 1. Widgets that >> have problems with this are at least Fl_Pack, to some extent also all >> widgets that allow scrollbars to appear dynamically when needed like >> Fl_Scroll, and probably also Fl_Tile. > > Yes sorry I did not fully explain it. layout() (and/or draw()) are not > allowed to change the size of the widgets. I agree this is a problem > with fltk1, and is also a problem with the way fltk2 is currently designed.
Thanks for the clarification. Agreed (and see below). > Instead the parent, in it's layout(), calls the new measure() on all the > child widgets, and uses these results and it's own rules to resize and > position all the children. The children then have layout() (or just > draw()) called and they are not allowed to change the resulting size, > and have to deal with whatever it is (though it can screw up in any > non-crashing manner if the parent disobeyed the results of measure()). That sounds reasonable, and I believe that this is the way it should be to design a useful resizing and automatic layout behavior. I agree that this should be considered (carefully) and this is probably the way to go, as far as I can see. I see one problem, though (but this SHOULD be solved then): In the past I saw tips so resize widgets in the draw method, and my first attempt in my own apps was based on this. The result was all kinds of small displacement (like "rounding errors") when resizing widgets - some widgets were positioned one pixel below (or above, left, right) of others that were intended to be on the same pixel line/row. Eventually I managed to achieve much better results by only moving and resizing widgets (and groups/children) only in their resize() methods. The problem and solution would be that we must disallow resizing in the draw() method, which may break lots of applications that are designed to do exactly that. We must also rewrite FLTK's container widgets, but this is easier, because we know what to do. The real problem is the user code that needs to be modified, according to the new features. Anyway, if we did this, code that still resizes widgets in their draw() methods would probably still work as before, but widgets using the new layout() (or whatever it's called) method would benefit from the new features. At least that's what I hope and would like to get implemented. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
