In one of the bug reports for Fl_Scroll, Albrecht asks:
> BTW.: Here we have a widget that exposes its scrollbars,
> and therefore it is possible that existing user code modifies
> the scrollbar widths by accessing the scrollbars directly.
> I'm not sure if this could have consequences for the
> scrollbar_size() method. What do you think about this?
Yes, it does seem like the user can directly change the
scrollbar sizes, because that size is being preserved
are part of the computations that happen during draw().
I don't think this impacts the new scrollbar_size() method,
as the 'old behavior' will persist if the new method is
not used.
However, it does affect the way I've been implementing
the widgets so that changes to the global Fl::scrollbar_size()
have an effect even on widgets that have been created already.
If I did that with Fl_Scroll, then any user changes to the
scrollbar's size directly will be overridden by the
above behavior.
I don't /have/ to implement Fl_Scroll to automatically track
the global scrollbar_size, but it would be inconsistent with
the other widgets I've done so far.
So I see two ways to resolve this:
1) Implement Fl_Scroll /not/ to track changes to the global
scrollbar_size() so that users can still directly adjust
the scrollbar sizes by accessing the internal widgets
directly, and simply document the widget works this way
in the Description.
2) Implement Fl_Scroll to track the changes (ie. always
recompute scrollbar size internally), and document
that one can no longer directly adjust the scrollbar's
size.
#1 is the least intrusive, preserving old behaviors, but it will
lack the ability for the app to globally manage the scrollbar's
sizes for this widget, as the other widgets (Browser, HelpView)
have this control.
#2 prevents allowing users to directly modify scrollbars, but
I don't think this breaks written contract in the docs; the only
use we document for direct access to the scrollbars is for
align(), xposition() and yposition(). The 1.1.x docs:
http://www.fltk.org/documentation.php/doc-1.1/Fl_Scroll.html
If implementing #2 really broke code in a bad way, I wouldn't
even suggest it. But it seems primarily cosmetic, making me
think we have some flexibility towards taking over scrollsize
for the good of UI consistency.
Suggestions welcome.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
