> > Reasoning: > > The main documentation would stay where most of the code is. In the > future this might change slightly because we will need to split the > device drawing code in different files for different platforms, but > IMHO still most of the drawing code and the docs could stay in the > base Fl_Device class. Deviations and additions would then have to > be documented in the derived classes (Fl_GDI_Display etc.). > > We should make the mechanics of drawing by different Fl_*_Device > classes public anyway, so that there is a clear interface how to > add other devices (e.g. frame buffer). > > Drawback: it could be confusing to have to switch from fl_draw() > to Fl_Device::draw() in the docs to find something, but once you > know how it is designed, this would probably be "normal". > > Note: this is only "thinking loud", I don't know if it is feasible. > Please comment. > > Albrecht
I've committed a series of changes to fully document the Fl_Device, Fl_Abstract_Printer and Fl_Printer classes. This is done putting comments in .H files. I'm conscious that this bends the rule, but this rule is not really practical for virtual classes where a member function has several implementations, so there is not a single place where the code for this function is. At present, there are two codes for each drawing function: one for the 'classical' display output, one for PostScript output. In the future, there'll be, hopefully, still others. I also noted that several instances of similar rule bending were present in the documentation (e.g., line 218 of FL/fl_draw.H) for the very same reason: avoiding duplication. If the result is not satisfactory, I'm ready to consider other solutions. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
