On 07.09.2009, at 22:46, Greg Ercolano wrote: > Fl_Browser has a built in struct, FL_BLINE, which manages > the individual browser items. > > Unfortunately this struct is 'secret', defined in the .cxx file, > and thus having no hope of being accessible to derived widgets. > > This is fine as long as no one tries to work with browser items > directly, but it seems Fl_File_Chooser /did/ need to do this, > and has its own definition of the FL_BLINE struct. > > Which means changes to the FL_BLINE struct will affect > other code that have to define their own private FL_BLINE > struct. (Such an ABI breaking change was made for STR#1739) > > So my feeling is, if FL_BLINE is really needed, maybe > we should at least make the FL_BLINE struct public, either > leaving it undocumented, or documenting it and possibly even > renaming it so that its public 'debut' has a naming convention > consistent with the FLTK interface. Hell, maybe it should even > be a 'class'..!
I think that the approach is wrong per se. A Browser should be nothing more than a group with the additional functionality of selecting one or more of its children. All other functionality already exists in Fl_Pack and Fl_Scroll. Every child would simply be a widget. It could be an Fl_Box, creating just a regular browser entry, or it could be a Checkbox, replacing the Checkbox browser, or it could be a group, itself containing an image and a label and a checkbox - whatever the user wishes. Fl_Browser could still provide the give simple API, but the internals should be a regular FLTK group. (BTW: a Group in a Group - something that is standard in FLTK - would readily make for a Tree browser...) Matthias _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
