This page is intended to collect ideas, informations, issues with the current library organisation and to define a new organisation of the libraries.

Modules

The idea is to split koffice in at least two modules, released at the same time:

kofficelibs with library that we consider useful for an external use, offering API/ABI stability (for a while)
koffice with applications and internal libraries

A koffice-plugins (with the plugins of koffice/plugins that depends only on part of kofficelibs) and katelier are other consideration to take into account.

Candidate for kofficelibs

List of library candidate for kofficelibs:

odf
flake
pigment

Current external use

geoshape

Flake shape using marble: http://websvn.kde.org:80/trunk/playground/office/geoshape/

Braindump

Application that use flake: http://bitbucket.org/cyrille/braindump/overview/

Comments:

some important GUI classes (such as KoDockerManager) for a functional flake canvas requires KoMainWindow/KoView

Proposal

I (boud) have been experimenting a bit. I'm not done yet, though, since our library structure is quite complicated. A preliminary dump of patches is at http://www.valdyas.org/~boud/lib-reorg. I'm also working on documenting and making a diagram.

Basic goals:

make it possible to use certain libraries independently from KOffice and independently from each other
make KOffice application link to as small a set of classes as possible
make it easier for developers to figure out what functionality is implemnenter where
make it easy to optionally replace KDE-based functionality with Qt-based functionality
achieve a stronger separation between GUI and logic

Basic implementation:

instead of basing everything on komain, make komain the MVC library providg doc/app/view (and filters). Move the startup pane stuff to the widgets library.
put store (make this optional, since Qt also includes code to read/write to an ODF store?), odf, pigment, resources, kotext, flake and most widgets before komain in the hierarchy.

 * in order to make odf more independent, add a KoOdfDocument class and make KoDocument inherit that.

make pigmentcms optional for koffice; make lcms optional for pigmentcms

* there are two ways to make this work: have a NO_PIGMENT compile option, or have a SMALL_PIGMENT option that compiles only on QColor-backed KoColor which can be used in flake and resources.

extract certain self-contained features from komain and possibly other libraries into independent libraries.
make koguiutil a base library for widgets containing some shared components like KoCheckerBoardPainter), make a library containing widgets in separate directories, themed by dependency. For instance, put all color widgets together.

Maybe after this is done a renaming round, komain -> komvc, koguiutil -> kowidgetbase or something like that would be nice, too.

Dependency diagram:

Note: my diagram drawing skill suck, especially now that I don't have Kivio anymore.

= Other things

The next step should be to figure out what of the functionality now contained in the applications could/should/would-be-nice-to move into separate libraries to provide functionality independent of KoMain.

kspread's formula/recalc engine?
kformula?
kword's page layout code?
krita's openraster implementation?
krita's layered image core?
karbon's resources model?

I haven't started on this yet, since the libraries alone are already quite a bit of work.