This page is intended to collect ideas, informations, issues with the current library organisation and to define a new organisation of the libraries.
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:
Current external use
Flake shape using marble: http://websvn.kde.org:80/trunk/playground/office/geoshape/
Application that use flake: http://bitbucket.org/cyrille/braindump/overview/
- some important GUI classes (such as KoDockerManager) for a functional flake canvas requires KoMainWindow/KoView
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.
- 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
- 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.
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?
- 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.