Looks like we have a team based on the four responses.
(Thank you Gustavo, James, Harry, Aaron, and Ben.)
And, YES, this is NOT user documentation. This
is developer documentation.
Dia documentation should (of course) use markup.
I guess there are two things needed for quick development:
* code needs internal documentation notes which can be
parsed into graphical/textual documentation
* graphical documentation should be not be just read-only;
alterations to graphical/textual documentation should seamlessly
pass back into the code
Basically, some people need to be doing top-->down
(graphical into internal code comments) and others need to
go bottom-->up (internal code comments into graphical).
Here are some initial questions.
* What is dia? (System-view documentation)
Summary information of the 1825 files in my dia tree directory
and their interrelationships.
(I volunteer to do this since wrapping and burning
application/system specifications is what I often do.)
* What tool(s) should be used?
Dia-UML primarily of course.
Others mentioned were gtk-doc and doxygen. The docbook sgml stuff
looks good, and since Gustavo swears by it, let's probably move
in that path? I like what it does with templates.
* What pieces of code should we comment up, work up first?
Here is a line-of-code listing of some of the code pieces:
1078 ./objects/custom/shape_info.c
1109 ./app/layer_dialog.c
1114 ./lib/beziershape.c
1115 ./objects/UML/association.c
1117 ./app/interface.c
1185 ./lib/properties.c
1205 ./objects/UML/class.c
1206 ./app/render_eps.c
1209 ./plug-ins/wpg/wpg.c
1280 ./plug-ins/cgm/cgm.c
1379 ./objects/custom/custom_object.c
1459 ./plug-ins/xfig/xfig-import.c
1615 ./app/render_libart.c
2694 ./objects/UML/class_dialog.c
I will set up a read-write CVS server and web page by
the end of the week for the four of you to use, as
well as anonymous access.
James, I'm a newbie, so feel free to provide better
guidance to any of this.
Everybody else, I'm a newbie, so feel free to laugh
or something. :)
-Scott
