Duncan Gibson wrote: > AlbrechtS wrote: >> BTW: Fl_Scroll could also be changed to allocate the scrollbars only >> when needed, and thus could be much smaller, if there are no scrollbars >> (the default when it is created or all widgets fit into it). The next >> step would be that every widget can also have scrollbars (if it is a >> group, then why not ?). If we set the already existing scrollbar flags >> to 0 (no scrollbars), then it would behave like a normal group (or >> widget). > > Maybe I have misunderstood, but this makes me uncomfortable. > > You want to allow a user to create a widget that initially has no children, > but when the users adds X number of children and exceeds > the initial width or height of the widget, or a child resizes when > a font is changed, you suddenly add one or two scrollbars and the > number of children increases and is no longer X.
Yes (add scrollbars), but also no (the number of children would still be X. A normal widget would never have scrollbars, because the scrollbar flags would be initialized with 0. The Fl_Scroll widget, e.g. would set the scrollbar flags in its constructor to have both scrollbars enabled (but only used, if the widgets don't fit, like it is today). > When and where are these scrollbars added? What happens to any index > into the children() that the user might have stored? If the user adds > more widgets, are they added before or after the scrollbars? Here comes the feature that the scrollbars would be private subwidgets. The user would not see anything of them in the list of children. But s/he can switch them on or off, even for "normal" widgets - however, this would only make sense for groups, of course. No, not really. I'm thinking of an image viewer that can zoom the contained image. If you click the zoom button, the content would not fit anymore, and you would get scrollbars. Of course, only if enabled. > I thought you were talking about seperating "fixed" and "optional" > children of the same widget? Or is that phase 2? Yes and yes, that would be phase 2, but it would be fully compatible. In fact, every group could have scrollbars, but they would be under user control and hidden from public view of the children() list. The only problem would be, as Fabien already mentioned, that every feature added to the base class would increase its size. > I'm confused. That was not my intent ;-) Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
