> Are the Flcc_HueBox, Flcc_ValueBox and Flcc_ValueInput classes really > supposed to be part of the FLTK interface? Or are they supposed to be > for internal use only? AFAIK, they are not referenced in the lib apart from their decl. and definition files...
> there is nothing to stop the user creating Flcc_* objects and using > them in application code. I noticed many times this kind of problem, Fl is full of it, and others. The reason why I didn't systematically transformed the code with private attribute (eventually friend keyword to make some internal classes use them) is that I am not keen on the side effects it would have concerning backward compatibility. This very delicate aspect as to be more discussed, for the record currently we can read in the sources: // the following methods (maxinum and mininum) are kept for compatibility // we must keep binary compatibility ... Binary compatibility is a very high restricting statement, do we need that anymore in 1.3 ? I guess not but would like to have some acknowledge about these. > Is it worth adding this as a \todo or an STR ? I would prefer to systematic \todo adding because if it is not very simple to achieve, one could (and will) forget to trace things... Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
