Fabien Costantini wrote: >> But even then, I reviewed recently the Fl_Group code and fortunately >> for us, the internal attributes to handle children (array_,children_ >> and size_) are all private ; so it could be quite easy to replace >> that 3 attributes internally by only one pointer on a structure >> encapsulating these attributes. When NULL, it would simply means >> that there is no children, when not null the children() would return >> the structure attribute children_.
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. 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? I thought you were talking about seperating "fixed" and "optional" children of the same widget? Or is that phase 2? I'm confused. D _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
