> I've used Doxygen before, for both commercial and personal software projects, > this would probably require a series of articles spanning several newsletters > to get a decent tutorial working. Either that, or risk one incredibly long > newsletter where folks are likely to tune out before finishing the tutorial. Just to clarify, I wasn't really the one asking for a tutorial, Guy Haviv was. I have used doxygen before as well, and it looks to me that explaining it doesn't really require a large tutorial -- there is no need to repeat the entire user manual, of course ;-) But a set of guidelines would be nice: which style do we use (Javadoc or Qt or whatever it is called), do files start with a @file comment, where do @author tags go, etc. (Apologies if all of this was already discussed before.) > When you say "only the public API" -- I'm assuming you also include class > attributes in that list? OBOS isn't a black box like Be is. Hmm, now I think of it, on personal projects I always document everything that isn't obvious, both in the public headers and inside the implementation files (private headers and sources). I guess it makes sense to do that here as well. Then we could use two different Doxyfiles: one to extract the documentation of the public API (the classes and their public and protected members), and one to extract the implementer's documentation (everything, including private members and stuff inside .cpp files). I think the OpenBeOS Doxyfile right now only includes .h files, though. Anyway, the reason I was asking was that it wasn't clear to me which approach y'all settled on (if any). -- Matthijs Hollemans All Your Software www.allyoursoftware.com