On 15.05.2012 11:53, MacArthur, Ian (SELEX GALILEO, UK) wrote: > >> I'd like to make a few additions to Fl_Spinner; comments? >> >> Fl_Spinner is a group with an Fl_Input and a few buttons; looks like this: >> _________________ >> | | ^ | >> | input area |---| >> |_____________|_v_| >> >> In my application, I need to change the color of the input area >> based on if the value is negative or positive, but it seems I can't >> because the input area is a private member of the Fl_Group. >> >> To do this, I could see a few approaches to modifying the widget: >> >> 1) Add a color() method to override the invisible Fl_Group::color(), >> and have it call the input's color() instead. >> >> 2) Make the input and buttons 'protected' instead of 'private' >> so that one can derive classes from it to access the members >> directly. >> >> 3) Do what other widgets do (like Fl_Scroll) and expose the >> internal widgets with methods, eg. >> >> myspinner->input() >> myspinner->up_button() >> myspinner->down_button() >> >> ..so that an app can access these directly without deriving a >> class. >> >> My thinking is all three should be done, though perhaps #3 is "too much"?. >> #2 breaks ABI, so that would have to be #ifdef'ed. >> >> Comments? > > #1 and #2 sound good (ABI issues aside) - not all that keen on #3, but then > I'm not all that keen on it in Fl_Scroll either and it actually works ok...
Same here, I'd vote to do #1 and #2, but not #3. #3 would make sense if we could also replace the internal widgets with derived classes (as has been discussed recently for scrollbars in Fl_Scroll or similar widgets), but then we'd probably need some more virtual methods in these (base) classes. So I wouldn't do #3, because we can't take back later what we expose now. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
