Greg Ercolano wrote:
> BTW, holding back an SVN checkin of Fl_Tree for the 'public scrollbar'
> RFC
> (large thread of patches to Fl_Tree in fltk.general) didn't want to
> check in
> public scrollbar stuff only to have to retract it if there's a better
> way.
I saw the patches, but didn't find the time to look at them closer yet.
From what I read about it, this is a great improvement, thanks.
> Greg Ercolano wrote:
>> I've been fleshing out Fl_Tree's API a little bit, as the one in SVN now
>> is lacking several features.
>>
>> Since Fl_Tree is very similar to Fl_Browser in behaviors and API needs,
>> I've been trying to use Fl_Browser as a model at times.
>>
>> One thing I'm wondering about: Fl_Browser has both scrollbars public.
... and Fl_Scroll as well.
>> Should I do this in Fl_Tree too, or is there a 'better way'?
I believe the better way is to make the scrollbars private or
protected and make one's own methods for all the methods needed.
Personally I don't like to expose too much of the innards of the
widget - among other reasons because public API's can't be changed
easily. One more reason is that you can't control what the user
does (in this case with the scrollbars). Changing the scrollbars
can affect other aspects of the widget, thus if you can access the
scrollbars only with Fl_Tree methods, you can control and/or
adjust these settings better...
>> The most common thing to want to do with the scrollbar is change its value,
>> easily be solved with a simple method.
+1 for making the scrollbars protected and adding methods, maybe
hposition() and vposition() [we shouldn't use position()].
>> But folks might also want to adjust its width, colors, step rate,
>> or who knows what.. in which case it might make more sense to be public.
I'd wait until there's demand for such methods. The scrollbars should
honor the global scrollbar width settings anyway, but everything else
shouldn't matter (at least for now). Such methods can easily be added
later (w/o breaking ABI, unless they are virtual).
>> I can certainly make it public; just wondering if there's a better thing
>> to do.
>>
>> Suggs on API design?
Currently not more than what I wrote so far...
[Side note: if the scrollbars are part of Fl_Tree's group, then I would
prefer to remove them from the group, just as I would like to do this
for Fl_Scroll etc., but that's another story and has implications for
event handling. Please don't take this note as a reason _not_ to commit
your other changes, this is just a general thought.]
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
