| |
| |
@erco77: I like your proposals, particularly
- scrollbar_v(), scrollbar_h()
The only thing that comes to mind is that _h() might be misinterpreted as "height" rather than "horizontal". I'd be fine with it anyway, but there's another option:
- scrollbar_x(), scrollbar_y() which stands for "scrollbar in { x, y } direction", resp.
... even though exposing the members is perhaps bad design, it's "the fltk way", and perhaps it's best to just accept the warts for what they are, and do a "cleanup" in a rewrite, which is what FLTK 2 I think tried to do (among other things).
This may be considered OT here, but if we wanted to wait for a rewrite to improve things that would probably be forever. :-( We failed with FLTK 2 and FLTK 3 because it's just not doable with all compatibility issues, hence I'd rather try to move forward step by step. That said, ...
I strongly believe that we should add new accessor methods for the scrollbars, but in my opinion they really should be protected (after thinking more about it) because fiddling with the scrollbars in user code (if public) can have strange side effects (e.g. the user hides the scrollbars but the widget (class) calculates space although the scrollbars are hidden, or the widget re-enables them during draw() etc. etc.).
But we can (and probably should) also add public methods to disable/enable scrollbars. This can be done safely because the class implementation can still control the scrollbars depending on the enabled/disabled status. W/o looking at the code of other widgets ISTR that we have this in one or more widgets with scrollbars.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.![]()
[ Direct Link to Message ] | |
|
| |
