documentation inside gideon

[Bernd Gehrmann]

On Fri, 8 Jun 2001, Thomas Fromm wrote:
> ive got a question in general about handling of the documentations in general.
> i don't think, that its an good idea to put the docs for every language what 
> gideon supports into the cvs. (e.g. php doc is ~9MB foreach language)
> 
> at the moment iam trying to make the documentation tree configurable, 
> that means, that we are able to add elements into the tree and configure them 
> seperatly.  (the path to the doc, .xsl description and so on.. )
> hm, maybe would it be useful, that the part writers can write their own 
> extensions to the classes?

It's one possibility to let parts add extensions to the documentation
tree, but I don't think it's most flexible option. For example, one
would then typically let the Python part add the python documentation
to the tree. But I want to browse Python documentation even when I'm
in a C++ project. As a main use of Python is to embed the interpreter
for scripting an application, this is not an unusual combination.

The way it is currently implemented is that all tables of contents
that are installed in $prefix/share/kdevdoctreeview/tocs (iirc) are
displayed in the tree. This works for the python, perl and php docu-
mentation if it is detected by configure. If this doesn't work for
you (or someone else), look in gideon.m4.in and add your distribution-
specific path in the 'phpdocdirs=' line. I think I'll also add some
more warnings in configure.in.bot so that the user who compiles from
source can immediately see when something went wrong without going
through the whole configure output.

For configurability I thought it may be appropriate to display
all documentation by default and let the user hide some of them
on a per-project basis in a dialog. The application wizard and
them import dialog would also hide some entries which are not
relevant for the specific project. For example, the PHP template
would install a project file that hides the Python documentation.

Better ideas are appreciated of course :-)

Bernd.


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«