Evan Laforge wrote: > I think fltk internals *could* benefit from plain old > non-controversial c++ features like classes and virtual methods, e.g. > use Rect and Point types instead of passing masses of ints in an > ad-hoc way and mysterious arrays (I'm thinking of Fl_Group::sizes_),
Yes, really good point, and Fl_Group::sizes_ is a very good example. This could be a class/struct that contains 2 fix Rect members for the group itself and the resizable, resp., and an array of Rect's for the children. This would probably make the code much easier to read and to understand. BTW.: Fltk 2 uses fltk::Rectangle internally. > and virtual Fl_Group::add so you can enforce invariants on children > (e.g. Fl_Scroll has its own clear() but it's not virtual so it's just > asking to be sliced off, and has fix_scrollbar_order sprinkled > everywhere to make up for not being able to override insert(), etc. > etc. 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... Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
