Matthias Melcher wrote: > On 15.02.2010, at 14:38, Albrecht Schlosser wrote: > >> Two big points that I would like to address in the near future: >> >> (1) an alternate version of Fl_Scroll that doesn't need the scrollbars >> in its children() array. This would also make fix_scrollbar_order() >> obsolete. Ideally this would be API compatible with the old version, >> so that code that accounts for the 2 more children doesn't break. I'm >> thinking of an alternate constructor or Fl_Scroll::compatibility(int), >> or so... Ideas welcome. In the worst(?) case we would use another >> widget name. >> >> (2) all sorts of Fl_Group's child modification methods (add, remove, >> insert, clear, etc.) should be virtual... > > Yes. And all child-related functions should already be in Fl_Widget. It would > not make the code bigger, but it would be oh so conviniet, particularly for > composite widgets.
I like this idea, but I remember that Bill started something like this for FLTK 2 and he had to remove it because of complaints of others. However, I don't remember why they complained - because it was buggy or because it would have broken too much code. There's still a branch named "widget_has_children": [svn co] http://svn.easysw.com/public/fltk/fltk/widget_has_children/ And while we're talking about this: scrolling (and optional scrollbars) would also be a nice property to have in Fl_Widget... ;-P > I would allow two types of children, those that are dynamically accessible, > just like the current implementation, and those that are part of a composite > widget, like the scroll bars in Fl_Scroll. That's exactly what I'm pondering about for a while (months?). > Another example is the F_Input combined with a drop-down menu for presets. > This is currently derived from Fl_Group, which is wrong (but the only > possible way). It should obviously be derived from Fl_Input and add the > drop-down features. ... or like ComboBox in Fltk 2: derived from [Fl_]Choice and adds the [Fl_]Input. I think that this would work in FLTK 1 as well, but didn't investigate. The smart part in this approach is that the main widget area is _split_ into two parts (so that event handling, clipping, and drawing works as expected), instead of _extending_ one widget and its (x,y,w,h) area. A simple handle() method can distribute the events to the right subwidget (see below). > So if Fl_Input had access to the functions handling children (or cousins, if > we need another name than children), this would be easy. I call them "subwidgets". A subwidget is a "private child" that is _not_ part of the children() array of the main widget (or Fl_Group). This would then be the scrollbars of Fl_Scroll, the second widget of Fl_Input_Choice, or any widget that is used to extend another widget and is either embedded or added with operator new. I had already started an experimental branch (branch-1.3-composite) in svn that would have solved some of the problems. The key feature of event handling is that a normal widget could be a parent() of another [ private child | cousin | subwidget ]. There's no need to have an externally accessible private children method or a general way of handling the private children (subwidgets). The only reason why I didn't add the modified Fl_Scroll widget at that time was compatibility: this would have broken code that assumes that there are two extra children in the group. The other problem is drawing and clipping, if the subwidgets (like the drop-down box in Fl_Input_Choice) are outside of the primary widget area. In my private copy I added a few simple methods like Fl_Widget::event_inside() that acts similar as Fl::event_inside(), and something like Fl_Widget::not_clipped() that acts similar as fl_not_clipped(), but lets the (composite) widget decide what its area is. I could go on, but ... that's stuff for FLTK 1.4 or later, isn't it? Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
