Michael Sweet wrote:
> I'm -0 on providing per-widget control of the scrollbar size - IMHO
> it only encourages inconsistent UI, and scrollable areas are not
> typically used in situations where smaller controls are used anyways.
Yes, I found myself writing the docs in such a way as to say
"Don't use this method unless you really need to override
global control.." and was including text recommending global
control through Fl::scrollbar_size() is better for the average
case.
It took more time to write the docs than the code.
But if we don't do that, then it's a simple matter of:
* Leave scrollbar_width() in place,
have it call Fl::scrollbar_size(),
document the method as deprecated, recommending
Fl::scrollbar_size() be used instead.
* Not add the new scrollbar_size() methods
Thing is, with that, the user would then have *no* way to control
the scrollbar size on a per widget basis.
Might be a general good thing to do that, but there's always those
oddball cases where it is needed.. and without those methods, there'd
really be no way easy way to change the scrollbar size for a single
widget, as the scrollbar sizes are determined during draw()/resize()
procedurally.
The code could probably be rewritten so that the scrollbars own size
could be used, instead of a separate integer. But then the global value
would only affect widgets before they're created, not after.
> That said, if you do add this to Fl_Browser_, you should also have it
> in Fl_Help_View and Fl_Scroll for API consistency.
I'd be up for investigating adding it.. would have to check out
how hard it is.
Fl_Text_XXX too, I imagine. Haven't looked at the code yet.
Think I'll hold on this until I see more comments.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
