Greg Ercolano wrote:
> 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?
-1 from me, because this would mean that all the actively maintained
code would have to be changed to get the improvements and bug fixes. But
see below ...
> 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.
This is also a point for Fl_Scroll::scroll_to(). The change fixes bad
behavior (or should I say properties?) of FLTK, but it breaks existing
code (mine, for example). In fact everybody's code who used
Fl_Scroll::position(int x, int y) to change the scrolling (and not the
widget's) position.
>> 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.
Yes, this is really a bug. This could have been fixed by subtracting 2
from the internal value of the children() method
int Fl_Scroll::children() { return Fl_Group::children()-2; }.
And if the scrollbars would have been sorted to the end after each
modification of the children array (they did _not_, you would have had
to call (re)draw() or resize() first), then nobody would have had to
care ...
> 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'.
Yes, I don't know how I found it, but I new it too. ;-)
> 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.
I can imagine to have a compatibility mode (#define
FLTK_1_1_COMPATIBILITY) that adds 2 to the children() method. That would
be easy :-) But then, if someone used code like
Fl_Scrollbar *my_hscrollbar = scroll->child(scroll->children()-1);
we couldn't help ;-)
Adding the old Fl_Scroll::position(int,int) method would be a simple
inliner in Fl_Scroll.H.
Could this be what you want?
But I don't think that having utf-8 doesn't affect anybody's code. In my
german language code there are lots of german Umlauts (äöüÄÖÜ) and the
sharp s (ß) that don't display correctly now with FLTK 1.3 (they are
ISO-8859-1 encoded). Although I think that I read that they should be
recognized and "translated" automagically, but maybe I'm wrong. Adding
conversion functions or translating the character constants to utf-8
would be my other options. And I didn't think about input characters yet...
BTW: Nothing has been decided yet, but I would really, really hope that
we decide to fix this. And it is good that we discuss this now - that
was one of the reasons why I wrote it in my CHANGES.branch file that
Fabien cited.
Albrecht
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
