Item for the sprint agenda: replacing kparts

[Boudewijn Rempt]

KOffice was built around kparts. KParts were used for three things:

1. to select the right koffice plugin to open a document from KoApplication
2. to embed documents in documents
3. to show documents in other kpart-enabled applications like konqueror

3. no longer works. 2. has been replaced by flake. 1. is giving us a lot of grief -- for instance, when a calligra application cannot show its config menu in the startup screen because the application's part actually hasn't been loaded, or when we need to create a whole part with everything to load a document in a filter, or when we want to show more than one document in one main window.

We already started to split KoDocument and KoPart, but I'm no longer convinced that that was the right solution. I think we need a deeper refactoring and remove the calligra-internal use of kparts completely. If, at some point, we create a kpart for an application for integration with, say, konqueror, then that is fine, but it should not be the way calligra works internally.

Here's my set of requirements for a new framework for calligra:

* needs a separation between document, view, mainwindow and application

The document is only responsible for loading, saving and keeping the data.

The view is repsonsible for painting the document

The mainwindow is responsible for showing a gui: menu's, toolbars, actions -- it is more or less the controller

The application manages views, documents and windows. A document can be in more than one view, a mainwindow can show more than one view and more than one document.

These concepts need to be abstract, so we can create different views, mainwindows and applications for different purposes (like a KDE, QML or a Qt based application, or a KPart for embedding in other kde apps).

I've been playing around with some test code of my own and I've investigated Friedrich's kasten framework (part of okteta). I think kasten is basically suitable for Calligra, but might need extension: it does do the separation between document, view, window and application already at least.

I'd like to put this on the agenda for the sprint and maybe do some exploratory hacking. I want to start with krita and then move other apps to the framework as needed.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl