Regarding actual FLTK doc tweaking, I expect I'll only be
enhancing what's already in place.. I take it you all did the
heavy lifting of converting the old html over to dox.
I hope the others won't mind me saying this, but the initial conversion
was very much a let's add
Duncan Gibson wrote:
I hope the others won't mind me saying this, but the initial conversion
was very much a let's add doxygen comment tags around the existing
docs effort. That meant that the bulk of the documentation became
available in the doxygen generated html in a very short period.
As you have already noticed, there are a lot of places where there are
comments that still hark back to the time when a single comment covered
two or more forms of a function, or multiple functions that all appeared
together. Now doxygen splits these functions apart, and the comment no
At first I tried using grouping.. this is supposed to work
according to doxygen chapter 5.2 on Member Groups:
/*...@{*/
/** Sets/gets the sortorder, used for sorting the tree items. */
void sortorder(Fl_Tree_Sort val) { _sortorder = val; }
FL_Tree_Sort sortorder() const {
Greg Ercolano wrote:
Strictly speaking not a doxygem problem, but at the source level there
are a lot of places where function/method signatures are not specified
in a consistent way, with (int,int,int) for example, or with different
parameter names in different places. We should address these
In a way, this might be good for us, because this way we can change
the .H files to use descriptive names in the prototypes so they'll
show up in the docs, while leaving the source code parameter names
the way they are, avoiding to have to carefully search/replace those
Duncan Gibson wrote:
It my mind the problem here isn't long or short names, but consistency.
Imagine that the declaration in the *.H has parameters with long names,
but the definition in the *.cxx file has short or missing names, and you
have to write the doxygen comments in the *.cxx file. It
Greg Ercolano wrote:
Note: doxygen will warn us if \param[in] xxx is used in dox,
but doesn't match the parameters in the prototype.
So if we use \param[in], that will catch that kind of problem.
Of interest: \p xxx does NOT do checking.
Maybe \p should be
Hmm, in trying to fix STR#2174 (SGI fails to compile 1.3.x),
most of the problem is to do with C++ style comments in old C file contexts;
SGI's native C compiler is strict about not groking C++ comment style by
default.
Apparently doxygenification and utf8 brought this on. caused some of this.
Albrecht Schlosser wrote:
2) Convert the few C++ style comments to C style.
This won't be hard, as there aren't too many.
I've already done this, and can check it in if need be.
+1 for #2: If there is one compiler that doesn't like this, there may be
more. Fixing this in
The source code in the utf8 dir is all nutty with non-4 space
code indents.
Thought I'd bring all that into compliance.. any reasons not to?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
11 matches
Mail list logo
