Michael Sweet wrote: > Greg Ercolano wrote: >> Albrecht Schlosser wrote: >>> because now the children() widget count would _not_ >>> anymore count the 2 scrollbars if I understood his >>> CHANGES.composite and related topics where he talks >>> about now having to adapt existing code with children-2() offset change. >> >> Is 1.3.x supposed to break existing apps? >> >> A while ago it sounded like 1.3.0 was going to be the >> time to implement long pending ABI-breaking fixes, >> large scale mods like utf8. >> >> I wasn't aware we were also going for code breaking mods >> in this release. >> >> What's the "general" definition of what 1.3 will be bringing? > > I'd say the goal is to avoid breaking things unnecessarily, but > there might be some side-effects of design changes (UTF-8, this > Fl_Scroll stuff) which may require small code changes.
Yes, both of them break my code, but I know that, and I think that we should document these minor changes. That's why I started that new chapter "Migrating Code from FLTK 1.1 to 1.3". It's still empty, however, but the Fl_Scroll stuff should go there (what we have already is Fl_Scroll::scroll_to() instead of the ambiguous position(). > That said, I don't know how much existing code exists that tries to > directly manipulate the child() array of a Fl_Scroll widget. AFAICS, the only documented behavior is that of Fl_Group, but the child handling methods don't work as one should expect from Fl_Group's documentation. And the internal fix_scrollbar_order() was not called after add()ing children, or using some other documented method like insert(), but only when drawing or handling events. As Stan said: We should get rid of this undocumented and undefined behavior. And, since it's not documented, we "wouldn't break contracts", as Greg said some time ago (IIRC). Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
