On Wed, 21 Mar 2001, Scott Harrison wrote:
> 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
[snip]
To get some immediately useful documentation, it may be better to look at
documenting things relating to specific tasks rather than deciding to
document everything (this was my "what documentation to people
want?" question). Some stuff is probably better to not document too
much, as it is subject to change, but other stuff stays more constant.
Here are some tasks people may want to do (and the parts of dia they
would need to know about for that):
- How do I write a new object type for dia?
- knowledge of dia object system and how to create new objects
- overview of properties interface
- dia rendering model
- info on load/save
- I want to do something with the XML files dia creates, or write new
files for dia to read
- Info on the basic layout of dia files (dtd, etc)
- common attributes of objects
- maybe more detailed info on specific objects
- I want to write a .shape file
- This is mostly taken care of in the doc/custom-shapes file.
There are probably other interesting tasks. Documenting something that
ism't of interest or is likely to change from version to version is
probably not the best use of your time.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
