From KDE Community Wiki
Revision as of 17:59, 6 December 2010 by Cyrille (talk | contribs) (Created page with '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...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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:

  • odf
  • flake
  • pigment

Current external use


Flake shape using marble:


Application that use flake:


  • 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 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.