On 05.05.2012 18:34, Greg Ercolano wrote: > Apparently Fl_Scroll's scrollbars are 'visible()' on construction, > ie. they are not hide()en by default. > > Currently no one sees this problem, because scrollbar visibility > is calculated during draw(). > > But perhaps it would be correct to have the widget initialize itself > with the scrollbars invisible, so that an app (for instance) trying > to determine the inner area of the scroll with Fl_Scroll::bbox() > before the widget has drawn, doesn't get a wrong answer. > > Thoughts?
Maybe, yes, but ... bbox() isn't reliable anyway, and a program that uses it now directly after initialization of Fl_Scroll would get the correct answer if it intended to add many widgets (and thus enable the scrollbars anyway). Otherwise, if you add only one widget (while scrollbars are off), you might change the scrollbar status (theoretically, but it is not implemented this way), because this one widget doesn't fit. And there are also flags to make scrollbars always on (hor. or vert., resp.), so that these would need to be taken into account. Oh, yes, and if you change the flags, would you want to change the scrollbar visibility, too? More questions than answers, I know. Is it worth it? I suggest to keep this in mind and do it when we make a correct (or at least a better) implementation, maybe in FLTK 3(?). As we already know, changing the layout during draw() is causing problems, and the correct implementation would do this when widgets get added or removed, the Scroll gets resize()d, or at least when bbox() is called, before returning the results. Maybe only the latter... Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
