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.
>
> 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,
I don't think that we can do this dynamically, as you suggest. At least
it would be difficult (maybe impossible ?) for virtual resize(int,int).
If you want _old_ behavior, you should set a configure option, e.g.
--enable-fltk-1.1-compat, or --enable-fl_scroll_compat, and this would
define #FL_SCROLL_COMPAT.
With your suggestion, those who want to use the new features would have
to derive from Fl_Scroll_Ex or explicitly disable compat mode. I think
that the new behavior should be the default, while users who want old
behavior should use a configure option.
>> 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));
> }
Yes, I did also think of this just after pushing the send button, but...
> ..assuming there really is an hscroll/vscroll to return,
> otherwise return NULL.
And that would break applications that assume that there would always be
two scrollbars. This would make it impossible to allocate the
scrollbars dynamically (means: only when needed).
There is another "Bad Thing (TM)": currently the scrollbars are public
members, and "void Fl_Scroll::scrollbar.align(int)" is documented to set
the alignment of _both_ scrollbars by setting the corresponding bits
FL_ALIGN_LEFT and FL_ALIGN_TOP, resp.
We would need to make the scrollbars private (and allocatable) and
provide new align methods to make it right.
Well, I don't know, ... maybe you're right and we should go the way to
make Fl_Scroll_Ex and leave Fl_Scroll as it is ???
Other opinions, anybody else ?
Albrecht
<unrelated> to this post, but:
> 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.
thanks for the pointer :-)
</unrelated>
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
