Michael Sweet wrote:
> Greg Ercolano wrote:
>> Is 1.3.x supposed to break existing apps?
>
> 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.
>
> That said, I don't know how much existing code exists that tries to
> directly manipulate the child() array of a Fl_Scroll widget.
Fl_Table does, so I assume it's not a small number.
I'd think any widget deriving from Fl_Scroll that wants
to do anything with children of the group has to know about
skipping over the scrollbars.
And a widget that wants to hide the 'specifics' of Fl_Scroll
underneath has to do things like:
int children() const
{ return(table->children()-2); } // -2: skip Fl_Scroll's h/v
scrollbar widgets
This could break a lot of existing extension libraries and
apps as well.
Many of the extension libs are no longer maintained, so breaking
them would really crimp acceptance of newer fltk releases I think.
It creates a situation where app programmers can 'boxed in' to old
releases; "I need utf8, but I also need Fl_SomeExtension which
doesn't support 1.3.x yet.."
I'm -1 on modifying base widgets in a way that breaks old apps
for compiling purposes if at all possible.
Can I suggest if API changes are made that affect existing code,
to derive a new widget (eg. Fl_Scroll2, Fl_Scroll_Ex..) or some such?
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
