In the process of moving Fl_Browser_'s static scrollbar size over to the Fl::
class.
Changing this will involve changing the old behavior no matter what we do,
as currently changing eg. Fl_Browser_::scrollbar_width() affects not only
the browser, but other widgets as well.
So thought I'd bounce this off you first what I plan to do.
Recap of Old behavior: Fl_Browser has its own internal *static* integer size
which if changed by either Fl::scrollbar_size() or
Fl_Browser::scrollbar_width(),
affects *all( instances of both Fl_Browsers (including those currently open)
as well as other widgets like Fl_Scroll, etc.
New behavior:
Have Fl_Browser keep an internal *non* static integer for the
scrollbar size, and have it initialize to -1.
As long as the internal value is -1, the browser will refer
to the realtime value of the global Fl::scrollbar_size().
This way if the app changes the global, all Fl_Browser
scrollbars are immediately affected. (Same as old behavior)
And, if the app sets the existing Fl_Browser::scrollbar_width()
method to a particular value, that will cause this instance of
the browser only, use that scrollbar size instead of the global,
allowing a 'custom' scrollbar size for just this one instance
of the widget.
The good things about this approach are it gives the best of both worlds;
global control by default via Fl::scrollbar_size(), and local control on
a per-widget basis with the local Fl_Browser_::scrollbar_width() method.
The only thing bad about this is it's not consistent with old behavior;
apps that assume changing Fl_Browser_::scrollbar_width() will affect
*all* instances of browsers (and other widgets) will be wrong.
Probably not a big deal though, since it wouldn't be a crashing type
of problem, and should be easy to fix. Also, apps probably don't change
scrollbar widths much anyway. And finally, it's debatable whether we're
even breaking contract, as the old docs for Fl_Browser_::scrollbar_width()
are (purposefully?) vague, saying only:
"Sets or gets the width of any scrollbars that are used."
..which is probably something we don't intend to support anyway, since
we don't intend to backwards-support the fact that Fl_Browser_::scrollbar_size()
affected other widgets besides Fl_Browser.
So looking for comments on the above.
Also, note there's currently a naming discrepancy between:
Fl::scrollbar_size()
Fl_Browser_::scrollbar_width()
..eg. 'size' vs. 'width'.
Should we document Fl_Browser_::scrollbar_width() as being deprecated,
and make a new Fl_Browser_::scrollbar_size() instead, to be consistent
with the global's existing naming?
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
