QOF help!

Neil Williams linux at codehelp.co.uk
Tue May 4 18:37:29 EDT 2004


On Tuesday 04 May 2004 10:41, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > The documentation produced, is there a problem with hosting it somewhere?
> > (If I keep it updated from CVS)? I've got the space to host it, if you'd
> > like, although somewhere on gnucash.org would be more intuitive it would
> > force the update burden onto someone else.
>
> Good question.  I could easily host it on cvs.gnucash.org.  I could
> even automate its generation, like a nightly cron job to checkout cvs
> and build the docs.  But that would presume that "cvs.gnucash.org" is
> the place to put them and not "www.gnucash.org".

Can't it simply be linked into www.gnucash.org using a symbolic link or NFS 
etc.? What's the design of the various sub-domains? (off-list if you like - 
I'll need to know about the list vs www domains for the search engine).

BTW. Why DOES list link to a https:// self-signed server? I can't figure out 
what is gained by encrypting the connection to archived content of a public 
mailing list.

As long as it's clearly linked from the 'Developer Information' list of links 
on the home page, does it even matter if it's in the cvs subdomain? It might 
help people who don't know doxygen to realise the link between code and docs. 
A lot of other sites have static documentation, the idea that doxygen puts 
the generation date into the pages should reassure new developers that the 
docs really do relate to the CVS code that they are looking through. The use 
of the same sub-domain would reinforce that and give a very positive 
impression of the docs themselves.

There is nothing worse than API documentation that is behind the C.

(A limitation of docbook of which I am well aware, even though I like 
docbook.)

> > The big advantage with doxygen is the links from one typedef to another.
> > I'll include doxygen compatible info in the files, certainly, but most of
> > the docbook stuff is for my own reference and has a different emphasis to
> > the doxygen output.
>
> IMHO doxygen should be the ONLY place for API documentation.
> However if you want to provide usage examples, or architectural
> documentation, docbook would definitely be a reasonable thing.

Exactly my plan, even though I had some C listings in the first draft, I knew 
it would be of limited use compared to the rest of the content.

> I guess it depends what you want in said documentation.  If it's
> descriptions of the API calls, IMHO this belongs completely in doxygen.

Yes, from what I've learnt so far, it does this very well. 

> > Off to learn about doxygen now, adding to GTK, Glib, QOF, and automake. I
> > may as well say this now, I'm NOT going to be able to learn Scheme as
> > well! I'll need help with the GUI dialogs etc. Plenty of time yet though.
> >
> > :-)
>
> The GUI stuff is easy.  Run "glade" and build the GUI.  :)
> As for scheme -- you don't NEED scheme for most things, so don't
> worry about it.

Phew!
:-)


-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040504/1d8cd5d9/attachment.bin


More information about the gnucash-devel mailing list