> I prefer Doxygen comments in the headers so that headers can be > distributed including the full docs, and no source code is needed. > However, since FLTK is fully OpenSource anyways, and most people seem > to prefer Doxygen comments in the source code instead, let's do it > that way. > > [basic doxygen usage tips removed]
I didn't expect anyone to provide the basics of doxygen, but thanks for clarifying those conventions. I was mainly concerned with: 1. the CMP/Coding Standards rules say that the doxygen comments should all go into the header files. IMHO that's fine for a binary-only development kit where the end-user only has access to the headers. For the developers, it's probably better to have the comments with the implementation code so that they are updated together as needed. Your first paragraph now lets me do that (if the other devs agree) 2. getting a basic skeleton in place is something that Duncan Q. User can do without knowing all of the internal details, but needs an agreed framework that the developers can flesh out as the modules are updated. I want to avoid unnecessary rework for others later. 3. the current documentation groups related member functions, such as Fl_Widget's active(), active_r(), activate() and deactivate(), or resize(), position() and size(). In an initial doxygenation these would likely be separated into lexicographic order. Maybe there is a doxygen expert who can explain how to group these during phase II once the basic comments are in place. I started to look at converting Fl_Widget to have the same basic doxygen comments as exist in the current documentation pages, without grouping. Maybe I should concentrate on completing that so that there is something to talk about. After that, people could claim files to work on to avoid duplication, and merge conflicts with ongoing work. Cheers Duncan _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
