On 09.12.2011 21:36, Bill Spitzak wrote: > On 12/08/2011 09:47 AM, Matthias Melcher wrote: >> >> There is something similar in FLTK 2. It has a virtual function named >> "layout()" that adjusts widgets sizes and available space. I am >> planning on using the layout mechanism in 3 - unless of course there >> is abetter way?! > > This is not working in fltk2. > > Having tried some more experiments I don't think that idea will work. > The intention was that layout() would alter the widget's size to any > requirements and then the caller (the layout() of the parent) would > adjust to this. But it would cause repeated calls to layout() and be > wasteful. > > New version would be to add a virtual measure function: > > void Widget::measure(int& width, int& height) > > This function should modify the passed width and height to take into > account any limitations of the widget. For most widgets it will enlarge > them to accommodate a minimum size due to the label and borders (though > it can do other things, like round to an increment larger than 1 pixel). > The values are preset to the size the caller wants (widget probably > should not make it smaller unless it has a really good reason, and this > is used to figure out wrapping so the height can increase as the width > gets smaller). The caller may disobey these values and force the size to > something it wants but the widget is allowed to mis-draw in this case.
We must really discuss such mechanisms and try to find a good way. It's a pity that FLTK 2's layout() doesn't work as expected :-( > There is no real need for a virtual layout() function because it is > always called immediately before draw(). So it may be better for draw() > to just check if the LAYOUT_DAMAGE flag is on to indicate a new size, > this will avoid overhead in the many cases where layout() does nothing. > This is pretty much how fltk1 works now. 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. I tried to handle resizing problems in nested Fl_Pack widgets (horizontal Fl_Pack within vertical Fl_Pack or vice versa), posted in fltk.general by a user, and I saw all sorts of unexpected behavior when I modified the Fl_Pack code (adding Fl_Group::init_sizes() at some places or whatever I tried). It seems that using something like layout() to query the widgets and resizing them before starting to draw them would maybe help, but I don't know. > One idea that is working from fltk2 is to put a "VERTICAL" flag on > widgets to indicate what direction they go in. This seems to provide a > lot of useful information to a parent about the desired layout, with > minimal overhead. VERTICAL or HORIZONTAL or NONE (UNSPECIFIED), maybe. Yes, I believe that this could be useful for a dynamic layout mechanism. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
