|
|
As noted in a post today, it's useful for applications/subclasses to access Fl_Help_View's scrollbars to, for instance, hide() them.
They are currently private: and are instances named scrollbar_ and hscrollbar_.
Options I can think of:
- Make scrollbars "protected:" or "public:" and named appropriately for direct access.
- Expose scrollbars via accessor methods that return pointers
- Expose scrollbars via accessor methods that return references
- Other?
Precedents:
- Fl_Scroll exposes scrollbar and hscrollbar as public instances
- Fl_Browser exposes "scrollbar" and "hscrollbar" as public instances
- Fl_Text_Display exposes *mHScrollBar and *mVScrollBar as protected pointers
- Fl_Tree exposes *_vscroll and *_hscroll as protected pointers
- Fl_Table exposes *vscrollbar and *hscrollbar as protected pointers
I'd like to hold back my vote on which I prefer for last, just to see what everyone thinks, as I'm not really sure what's best.
What I can say is:
- I don't like camel case exposed in Fl_Text_Display for its scrollbar member names, so let's not do that
- I don't think it's good to expose members with underbars as a prefix or suffix (e.g. Fl_Tree)
- I like the names "scrollbar" and "hscrollbar" for vert/horiz scrollbars respectively. Whether we should expose them as methods or direct access, not sure. I generally prefer using pointers for everything, just so construction time can be specific, but there may be reasons why FL_Help_View uses instances instead of pointers and 'new'.
— 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 ] | |
|
| |