Allen Bierbaum wrote: > I like the way you are going about this talking about what we want the > documentation to be before talking about what tool or method to use to > generate it. > [snip]
I agree with both of you. Everything sounds like good ideas, especially what Allen wrote about as looking at different documentation 'users', how their needs are, as well as set up easily accessed "summary pages" that describe various subsystems from a higher level. Using QT is good, as there's always merit in steal^h^h^h copying good design. :) OSG 1.x had reasonably good 'overview' pages, but they were hard to find and navigate. Jowever, if we copy them to 2.0, freshen them a bit and add a good index (on the doxygen main page) similar to qt's first page, I think we've come a good way. Using FCD edit is good. I mostly use the docs to find which field does what. (With StateChunks, it usually entails mapping a field to a gl-call. A reverse mapping would be nice, but it is some work to write that.) I had an idea about using GCCXML instead of doxygen (as we use that for PyOpenSG) but it will probably not work as GCCXML probably doesn't parse comments. (Otherwise it would've been nice to use a single c++-to-xml parser in OpenSG, instead of two differ) Will try to provide more detailsanswer later. The call-for-discussion and entusiasm about fixing this gives me a good feeling. :) Cheers, /Marcus ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
