>>> 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.
Not if the new widget was just a simple wrapper class around
Fl_Scroll that disables COMPAT mode, eg:
// WRAPPER CLASS
class Fl_Scroll_Ex : public Fl_Scroll {
public:
// CTOR
Fl_Scroll_Ex(..X,Y,W,H,L..) : Fl_Scroll(X,Y,W,H,L) {
Fl_Scroll::compat_mode(0); // disable compat mode for this widget
}
};
..where "compat_mode()" is normally /enabled/ by
default within Fl_Scroll.
Would that work? I'm guessing that's how Microsoft does it,
though I've never dared look at Microsoft's internals
any more than I'd dare look up my grandma's dress. ("CANNOT UNSEE!!")
> 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 ;-)
Maybe we could:
Fl_Widget *child(int index) const {
if ( compat_mode() ) {
if ( index == total + 1 ) return(hscroll);
if ( index == total + 2 ) return(vscroll);
}
return(grp.child(index));
}
..assuming there really is an hscroll/vscroll to return,
otherwise return NULL.
> 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).
Possibly iconv(2) can help you here..
It can do conversions from just about anything to anything,
with UTF8 being the desired 'destination' in this case I'd think.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
