Thread: [Scrollkeeper-devel] Re: ScrollKeeper

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

On Mon, Apr 09, 2001 at 04:50:10PM +0200, Cornelius Schumacher wrote:
> Hi Eric,
>=20
> I had a deep look into ScrollKeeper and now I have some questions to yo=
u.=20
>=20
> There are three things we would have to do to make use of ScrollKeeper:
>=20
> 1) provide OMF meta files for the documentation

I raised this point when the scrollkeeper project started. I said that
this information should be extracted as much as possible from the DocBook=
 file.
This includes the abstract, the keywords, etc. It means that we need a sc=
ript to
extract it.=20

For the OMF data that are not in the DocBook file, it could stand in a se=
parate file
along with the DocBook file, just like we had NIF files at the side of th=
e
LinuxDoc files. Or even better, we could extend the DocBook DTD to accomo=
date
for the new tags, do you agree Frederik?

I also suggested that on the long run the OMF data become
part of the standard DocBook, do you remember, Norm?

> 2) provide a documentation browser, which can read the ScroolKeeper dat=
abase
> 3) provide some support for the existing documentation browsers like=20
> khelpcenter and docview.
>=20
> 3) is currently addressed by doctool.

The new doc browser from Coolo which can render DocBook files directly
might also be a good place to do this.

> For 2) we would have to extend or rewrite khelpcenter, that's feasible

khelpcenter needs some maintenance anyway. For example, with the new po m=
echanism
we will have English section identificators only and we can remove the an=
chors
mechanism then.

> and 1) is ... a lot of work.

Adding the meta information and translating it is a big work, but the ext=
ra software
infrastructure is not.

Yes, since we are already doing a huge translation effort with DocBook
files, moving to XML, etc, we might need to postpone a part of this effor=
t.

But please note that we have been doing much bigger things than this alre=
ady,
and that we can do it progressively.
=20
> The GNOME people apparently already include OMF data in at least a subs=
et of=20
> their packages and they use Nautilus as documentation browser, which su=
pports=20
> reading from the ScrollKeeper database.
>=20
> How do you think about using ScrollKeeper in the context of KDE?

I strongly support it.

> As I've=20
> understood, ScrollKeeper is designed to be independent of a specific de=
sktop=20
> environment, but integrating the required meta information into the KDE=
=20
> documentation is a big task. Do you think we should do that?

Definitly, yes, because it's increased quality for the end user. When and=
 how we
do it is another topic.

--=20
=C9ric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for eBusiness
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

Thread: [Scrollkeeper-devel] Re: ScrollKeeper

scrollkeeper-devel