On Tuesday 04 May 2004 10:41, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> 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
pgp00000.pgp
Description: signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
