Calligra 3.0 for Qt 5.1?

[C. Boemann]

On Monday 29 July 2013 12:11:25 Boudewijn Rempt wrote:
> I want to propose that we start porting Calligra to Qt 5.1 now that 2.7 is
> released. Jolla is funding KO GmbH to work on porting the core, so this is
> a good moment to get started. On the other hand, we're in the middle of
> gsoc and users still want new features and bug fixes. And there is quite a
> large number of (Krita) users who actually use git master for their daily
> work.
We will always be in the middle of something important. Gsoc, or some 
restructuring or another

> 
> I see the following options:
> 
> * git master becomes the Qt5 branch. Work on gsoc, features and bug fixes
> can go on in Qt4 based branches, and the patches need to be ported to Qt5
> when merging to master.
> 
> * we keep a qt5 branch and regularly merge master to the qt5 branch. Big
> refactorings (komvc, build system changes) should only happen in the Qt5
> branch. New features and bug fixes and gsoc results can be merged to
> master.
> 
I would prefer to port in master and target 3.0 as our next release, and do it 
as fast as possible.

> For the porting approach, there are also some issues and options:
> 
> * Jolla is Qt 5.1 based with some patches from Qt 5.2
> * KF5 is Qt 5.2 based
> * KF5 is not ready yet
> 
> As an example, I wanted to figure out the easiest way to get at the xmlgui
> framework, without building all of KF5 but just the libraries we need. The
> process went like this:
> 
> Build dependencies manually (there is no depedency tracking inside KF5):
> 
> 1. libkdeqt5staging
> 2. tier1/kcoreaddons
> 3. tier1/kconfig
> 4. tier1/kcodecs
> 5. tier1/kwidgetsaddons
> 6. staging/kwidgets
> 
> And here the system broke down, because staging/kwidgets couldn't find
> kfontchooser.h , even when it's installed already from kwidgetsaddons.
> 
> 7 staging/itemviews -- and itemviews/tests depends on staging/kiconthemes,
> which depends on itemviews.
> 
> Finally, I never got staging/xmlgui built.
> 
> My conclusion: depending on KF5 is not yet possible because KF5 needs Qt
> 5.2 which hasn't been released yet and it is itself not yet usable.
> Depending on KF5 will make working on Calligra 3.0 a lot harder for
> everyone involved.
> 
> One option is to follow the ideas I outlined earlier:
> 
> * Port Calligra to Qt 5.1
> * Create a temporary, local kdefakes library that has the bare necessities
> to make Calligra run.
> * Where possible (i.e., karchive) use the relevant KF5 framework library.
> Maybe we should make a local copy in those cases, though, to make building
> easier for ourselves.
> * After finishing the port, start depending on the relevant KF5 libraries
> when they get done.
Yes, since we want to do it as fast as possible we need to go with stuff that 
is stable. I like your proposal of how to do it. I think we should decide on 
local copies on a case by case basis, or make branches in their repositories

> 
> As I said, we have some funding for porting the core parts of Calligra:
> the libraries, words, sheets and stage. The various utilities don't need a
> lot of porting. I'm going to pick up porting Krita in copious spare time.
> As for, Flow, Karbon, Plan, Kexi, Braindump and Active -- whenever porting
> by script works, they will tag along. But it will take some community
> effort to really port those apfplications!
I think this is the biggest issue. Flow will follow along without a problem 
because of it's ties with Stage. Karbon and Braindump will probably be 
relatively easy as well.