Dear Rene and rooters, > Two kinds of parsers are required with totally different levels of > sophistification. A header file parser to digest the class information > and the class implementation parser. [...] > With THtml, we decided to use the information digested by rootcint/CINT > when running a ROOT application. Another possibility was to develop a > tool (call it rootdoc) like rootcint that could be run independently. I never planned to rewrite the class layout parser, I think CINT is just fine: It knows all the classes, inheritance structures etc. In my point of view it wouldn't make sense to rewrite CINT's header parser. But, as you pointed out, there is another parser involved in THtml: The source parser which generates comments from the source, links for the source and the HTML output of the source code itself. This parsing is format independent, only the output is format dependent. > It is my view that if a project aiming at rewriting THtml is started, > one should think using XML instead of html/LateX. Then the problem > will be to develop several DTDs for the final targets (html, > text, LateX, etc). I agree that it would be very nice to have XML and pure text output. But once we have a better class structure (divided into parser and output) I think it's much easier to write a LaTeX output class than to write a LaTeX DTD... Anyway, the point is: Separating source parser and output generator will prove helpful, even if we just add plain text output. > I am interested by the pure "text" output (let's call it "man pages"). [...] > In this way, > the help could be instantaneous, in pure text (man pages) if used > from the command line, or with nice hyperlinked text when used > from the GUI. > A help search path could be introduced. the user interface could be > via object.Help (calling TClass::Help) and in the GUI, the Help > function would be available in all context menus. Great idea. Sure, why not! Once we have a new THtml we only need a documentation display for ROOT. > A final point that we already discussed together: the inheritance diagram. > When we developed the original THtml, we opted for a Postscript output > showing the inheritance. The experience shows that this is not > very convenient. > A cliquable gif file would be better and it should be inserted in the body > of each class.html file. Other systems like doxygen, doc++, etc have > been developed meanwhile with better look&feel. may be the authors of > these systems would be interested in a cooperation. Doc++ is (as far as I know) not developed any more - doesn't need to be, it's working quite well. Doxygen is really nice (though I'm not so sure about its better look&feel...) - but there is a problem with co-operation with other documentation products: We completely rely on CINT to generate the class information - all the others don't, and we have a different source format for the class & method documentation. We could still "share" the generation of the (inheritance, usage etc) graphs - or we just do that ourselves, too. Once we have the png / gif interface... Cheers, Axel.
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET