Hi Axel, Some comments about possible THtml development/extensions/replacement. 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. The first one is already there with rootcint/CINT. It provides a complete information on the class structure, inheritance, data members, member functions, comments, typedefs, enums, etc. 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. Both approachs have pros and cons. A rootdoc like system seems attractive at a first glance. However, in order to obtain the class description, the high level interface developed for ROOT will not be available (TClass, TDatamember, TMethod, etc). Instead one would have to rely on the low level CINT calls (C interface). Another problem associated with this approach is that a class may be ambiguous at this level. A header file may contain ifdefs (machine dependency) or templates that cannot be resolved at this point. A compromise solution could be to link the rootdoc+ with the ROOT libs and user shared libs (at link time or dynamically). The first parser must be able to understand full C++. The second parser has to recognize only some basic constructs: start/end of a function, comments, C++ keywords and obviously "object.Function(params)". As you say in your mail, it would be nice to have several output possibilities: html, LateX?, pure text, XML. Before leaving the project Nenad Buncic (who wrote most of the THtml class) had started this exercise. 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 am interested by the pure "text" output (let's call it "man pages"). I think it is essential to develop a coherent HELP mechanism in ROOT that could be used in command line or the GUI. Initially, we thought that the html pages would be sufficient, but this is far too slow in an interactive application. It would be nice to have a new tool generating a myApplication_help.root file. For ROOT itself, one could provide a $ROOTSYS/etc/help.root file with a highly compressed help corresponding to the documentation as it is generated today by THtml. Each class will be a directory in the file. Each function a key in the directory. 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. 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. Rene Brun Axel Naumann wrote: > > Hi, > > > -----Original Message----- > > From: owner-roottalk@pcroot.cern.ch > > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Christian Holm > > Christensen > > Subject: Re: [ROOT] Table output > [...] > > This sort of brings up another thing: It'd be nice if ROOT had > > something parallel to THtml that could write > > LaTeX/SGML/DocBook/etc. formatted files > > I agree. The only problem is that THtml is... well... not really forseen to > be output format independent. Content and output format are not decoupled. > > Obviously this approach is not really nice. Not only does it make context > dependent HTML formatting difficult (e.g. if one want to specify how the > documentation output of inline functions should look like), but it also > blocks the implementation of other output formats. > > The most natural thing to do is to more or less completely re-write THtml, > split it up into a parser which stores the documentation content-wise (say, > TClassDoc) and output classes (say TClassDocLaTeX, TClassDocHtml, ...). > (Sometimes methods of the output classes need to be called, e.g. to put a > link around some text, but all that could be implemented completely format > independent). This would also allow the HTML code generated by the > documentation to be fully configurable, one could specify the layout for > each part of the documentation separately. > > Suppose I'd volunteer to rewrite THtml - would someone volunteer to > implement "TClassDocLaTeX"? I won't be able to finish re-writing THtml > before mid next year; if someone else could do this job earlier I'm happy to > get rid of it :-) > > Cheers, Axel. > > > [Ok, I'm throwing out a lot of suggestions today which I > > unfortunately do not have the time to do something about myself - > > sorry about that - anyway, it's suggestions to put (far down) on the > > TODO list if you feel like it.] > > > > Yours, > > > > Christian Holm Christensen ------------------------------------------- > > Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 > > DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 > > Denmark Office: (+45) 353 25 305 > > Email: cholm@nbi.dk Web: www.nbi.dk/~cholm > >
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET