API docs; functional or pretty?
Frans Englich
englich at kde.org
Thu Jun 22 20:40:14 BST 2006
On Thursday 22 June 2006 19:08, Thomas Zander wrote:
> On Thursday 22 June 2006 20:40, Frans Englich wrote:
> > > What can we do with the problem Adriaan put forth that as long as the
> > > docs don't look and behave like the kde - site (which IMO makes them
> > > unusable) we can't have them on developer.kde.org?
> >
> > I vaguely recall having bounced DKO with Adriaan in private mail. I
> > have this idea of fully integrating all documentation concerning KDE,
> > API documentation, possibly user manuals, guidelines(HIG, HOWTOs, etc),
> > into the strongest and common denominator: Docbook.
>
> Docbook is a storage format and so your answer has little to do with my
> above question ;)
It is true that Docbook is storage, but sometimes one must look at that area
too because it affect others, such as displaying.
> > By having everything in Docbook, we can link across everything(say,
> > from the HIG to a particular enum in a class), index across everything,
> > and export to whatever format you like, etc, etc. Of course,
> > considering I'm an XML geek, I'm having trouble breathing while
> > describing that.
>
> Read the (xml) tags files doxygen creates[1], it allows you to do all that
> while avoiding a conversion to docbook only to convert from docbook to a
> readable format later on again.
I don't see how.
Remember that only the API documentation is in doxygen, not any HOWTOs or
guidelines. You can treat them separated, but that will prevent cross-linking
and it will still be inconsistent. I think this demonstrates how an issue of
storage format/backend, affects the end user result.
The tag files are neither not that interesting. Writing sensible stylesheets
for that is a huge task, while Docbook XSL has some of the most well-written
and most sophisticated stylesheets that can be found.
Of course, if ones only interest is to change the style of the current Doxygen
output, bringing in Docbook makes little sense. But if one wants to look at
the general inconsistency problem at DKO, I think looking in that direction
is sensible.
Cheers,
Frans
More information about the kde-core-devel
mailing list