Re: [fltk.development] RFC: Fl_Spinner API additions
Fl_Spinner is a group with an Fl_Input and a few buttons; looks like this: _ | | ^ | | input area |---| |_|_v_| [..] 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. Albrecht: I'd vote to do #1 and #2, but not #3. Ian: #1 and #2 sound good (ABI issues aside) - not all that keen on #3 Done: #1 and #2 implemented in r9500. Not doing #3 (expose internal widgets with methods) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Fl_Spinner API additions
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... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Fl_Spinner API additions
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 fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
