Duncan wrote: > Fabien wrote: > > I switched the undoc off because I believe all important files to > > document are done. Also, we should now focus more on other warnings > > and on the overall structure of the documentation. > > Maybe it's just me being picky after using lint, etc. for 25 years, > but I always prefer to address, correct or silence the individual > warnings rather than disable warnings completely. This has saved me
OK, sorry I wasn't clear enough, so let me be more clear and specific: We *don't* remove all warnings here, we just don't want to see hundreds undocumented api warnings _because_ I assume we know a bit what are the most important things to do by priorities in the doc right now: - Be CAREFUL about the content that we add more than just wanting to remove all warnings or comment all API's. In particular, check that the most stastically used API like common dialogs, are not wrongly commented ... - Pay attention to _other_ warnings and solve them first. Seriously, would you just notice a new severe warning appears if it is immersed in 200 warnings with undocumented api that you perfectly know about and obviously don't read every time your run doxygen ? - Then solve lower priorities warnings like the undocumented ones when you get the time to do it, thus activating locally the undoc warning because you *will* fix a bunch of these warnings right after that. Once it is done (or let's say 90% is done) ; activate again the undoc warnings in the svn. BTW, I prefer to keep warnings unsolved rather than having a reflex using the ifndef FL_DOXYGEN clause to skip the problem (which is sometimes justified but not always) instead of a real fix ... > > I believe we can't afford to let to the user the task of generating > > the documentation, as he may not have doxygen, but I may be wrong. > > But in the case we should not worry about this, we could neglect the > > important amount of generated files. > > I have to confess that I usually bring up the copy from the FLTK site > with the comments and don't usually look at my local copy. > > What I would suggest is that the generated html is made available via > the document links on the site. Hmmm, and what about the (mobile) FLTK users that are willing to work correctly without the internet available ? Furthermore, if you happen to provide sometimes development services directly at your customer office with its own material, the less you install before you get operational the better ... Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
