From kde-core-devel  Sat May 12 22:18:14 2007
From: Thomas Zander <zander () kde ! org>
Date: Sat, 12 May 2007 22:18:14 +0000
To: kde-core-devel
Subject: shared-ODF-lib
Message-Id: <200705130018.14656.zander () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117900834226961
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1381686.uOlTuv8hza"

--nextPart1381686.uOlTuv8hza
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

intro;
KDE developers (kdeedu /okular / etc) want to have better integration with=
=20
ODF. But having to parse the XML and write it yourself is a bit too much=20
for them. So the question is; can the KOffice crew create a shared=20
library?

We identified 3 use cases;

A) kvoctrain (kdeedu) is thinking about moving its native fileformat to=20
ods. A spreadsheet with the data.  No formatting needed and the only=20
thing it will use this library for is loading / saving. This implies we=20
never will need to, for example, have the library return the calculated=20
value of a formula like '=3DSUM(A1, B2)'

B) An application wants to use spreadsheet features like printing or=20
calculating values etc. Or load a ODF-Document and get information like=20
the number of pages or even print it on screen (like Okular wants)

C) KMail could want to load / save richtext from / to ODF into the=20
composer window.

The solution we (at the ODF meeting) agreed on:

* We will create a new module in subversion which koffice libs will depend=
=20
on. (kodflibs). After the 2.0 release.
We move code from koffice libs there for basic reading/writing of ODF=20
XMLs. This includes some of the KoStore library, the helper classes like=20
the OasisContext which are used for saving/loading.
This will satisfy the kvoctrain use case (A) by allowing it to use a=20
reasonably high-level API for loading/saving the ods file.

* In that new module we also move Flake.
Note that this does not mean moving implementations like the text-plugin. =
=20
It just means external apps are capable of searching for installed=20
flake-plugins and loading + showing + saving them.
This satisfies use case B by allowing apps to load content and use dbus to=
=20
interact with it other than what flake already allows.

* We move the KoText library to the extra module.
Note that KoText does not include text layouting or dialogs or displaying=20
code.
It will include code to save the QTextDocument plus the ODF addons to an=20
ODF-stream and will satisfy use case C.

=2D-=20
Thomas Zander

--nextPart1381686.uOlTuv8hza
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGRj0mCojCW6H2z/QRAq2iAKCs4wIBRRqJRf7t50JW1gM1gx2ZCACdEVa/
h+YAcWMhZBxZfXcTm5ByDm4=
=bBdu
-----END PGP SIGNATURE-----

--nextPart1381686.uOlTuv8hza--