Greg Ercolano wrote:
> 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?
Those of us actively maintaining our own code and libs can certainly
fix our old code, and do things like:
int children() const {
if ( FL_MINOR_VERSION < 3 )
return(table->children()-2); // -2: skip Fl_Scroll's h/v
scrollbar widgets
else
return(table->children()); // (fltk 1.3.x and up)
}
..so that it will work on 1.3 and older.
I'm just concerned that unmodified old apps will still compile OK,
but will behave strangely. Would be good if we could discuss ways
to avoid this, if possible.
> 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).
Heh, it's true this behavior is undocumented, so /technically/ it's
not breaking contract to make the change.
However, the fact it's undocumented in this case I think has more to do
with it being a doc omission, likely because the fltk documentation style
is not to document methods for base widgets in high level widgets *unless*
the methods are overridden. Here the methods aren't overridden, but
paradoxically behave differently in Fl_Scroll due to the widget's internals.
In truth, I think anyone that's ever had to use child() and children()
in the context of Fl_Scroll /had/ to encounter this and code around,
either by RTSL or by asking the group and getting an answer of
'yes, you have to skip the scrollbars..'. It's certainly been asked
and answered on the group enough to be considered 'documented'.
To my knowledge, this is the first time fltk will have made a change
to a base level widget, so I think it wise to at least carefully
consider options that avoid silently breaking old code if possible.
I'm not dead set against the improvement, I just think some discussion
about if there's a way to make such a change while minimally impacting
old code would be a worthy exercise.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
