gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New documenation look


From: Adrian Robert
Subject: Re: New documenation look
Date: Tue, 22 Jun 2004 19:56:05 -0400

Hi,

I just checked a bunch of additions to the Base library GSdoc to CVS, so the frames gsdoc HTML will have something to display. Actually most things were well-documented already; I just filled in some missing stuff, mostly from looking at Apple's docs and/or the code itself. If anyone notices any errors, you can email me (arobert at cogsci.ucsd.edu).

A note to anyone who has the chance to document classes in GUI or elsewhere, adding a comment to describe the class as a whole can be helpful even if the methods are already documented, particularly for people who are new to the class.

I also checked in updates to the programming manual I mentioned a while ago. Also added are the beginnings of a similar manual for GUI. Here, like with Base, a shorter, sweeter alternative to the Apple documentation would be a good thing. I don't have plans to work on it at the moment, but maybe someone who is familiar with the AppKit architecture would have some time? ;-)

I made a top-level documentation page that gets installed into System/Library/Documentation when you do the 'make' in base/Documentation. If anyone wants to improve this, be my guest!

BTW, there were a couple of requests to generate a PDF version of the manual. This would seem like a good thing to have in place of the current postscript version that gets installed. There is a "texi2pdf" command in at least my texinfo distribution. I'd like to switch the "texi.make" rules to use this by default instead of the texi2dvi + dvips toolchain. This means you can still generate .ps by passing arguments to the documentation make, but by default it will do .pdf (in addition to .info and .html) instead. I don't want to do this if some systems are depending on the .ps being generated in the default case though. Anyone have an opinion?

Regarding the suggestion to not document private instance variables, I will look into this. Note that I changed autogsdoc already to put the ivar docs after the methods docs by default, so at least they are out of the way.

Adrian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]