Calligra 3.0 for Qt 5.1?

[Friedrich W. H. Kossebau]

Hi Boudewijn & all,

Am Montag, 29. Juli 2013, 12:11:25 schrieb Boudewijn Rempt:
> 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.
> 
> 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.
> 
> 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.
> 
> 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 applications!

Great to see that Jolla values Calligra that much to fund the porting. That is 
nice news and makes me happy. Thank you, Jolla, and thanks those who made this 
happen! :)

But: having this influence how Calligra is ported to Qt5/KF5 reduces my 
happiness. Especially as this currently means, at least by the result of your 
investigations, that any nice enhancements that using kdelibs have brought and 
that using KF5 would possibly continue to bring (unless pushed upstream into 
Qt5) will be lost. So, in fact, Calligra will be less useful to people on 
Linux, compared to the Qt4/kdelibs4 based version, only to please Windows 
users and Jolla. That would suck a lot IMVHO. And first removing all kdelibs-
stuff, to add it back later seems like wasted effort to me, at least from the 
POV to get a 100 % of what there is now.

So I would rather see the Jolla-funded work to go into a branch, as you 
propsed in the second option, with just the core libs and apps as defined by 
"core" enabled, and keep master the Qt4/kdelibs4 feature branch for now, until 
the felt majority of contributors to Calligra (by number, not commit 
percentage) is ready for switching their development to Qt5/KF5 as well.

Because, who will work on the port? I guess for now only those run by the 
funding, and perhaps some. But the whole contributor crowd? Also, what does 
"core" mean for the funding? Really the XMLGUI QWidget-based apps? Would it 
not make more sense to investigate the funding into proper porting to 
components that can be properly used both with QML- and QWidget-based apps, so 
be usable for other Sailfish/PlasmaActive/BB10/UbuntuTouch type of programs 
and also still the plain old desktop style?

It takes some effort to switch the devel environment to Qt5/KF5, learning all 
the new things and fighting any problems of that young version. Do you think 
everyone can follow instantly?
And should master not be the always-releasable branch?

I would not join the Qt5 effort in the next few months. For one I still have 
some old branches I would like to finally get into master. So I am actually 
caught by surprise, would have liked to have more preplanning.
Doing both feature development and porting does not go well, I guess everyone 
agrees.

Also for me only Qt 5.2/KF5 is a sensible goal, as it will mean as less 
feature-loss during the port as possible, and will also mean feedback to the 
KF5, which I would like to give, because it is so important to the whole of 
KDE software. Winwin.

So my proposal would be:
* Do the Qt5.1 port in a branch. Take the "core" as defined by you/Jolla and 
with that pioneer a new architecture that easily enables touch-device-style 
and desktop-style. But do not touch the rest and lose your time there, just 
focus on that core and make it rock. But document any porting steps, so they 
can be replayed on the rest.
* Feature-freeze the parts of Calligra that get actually changed a lot in your 
port, to prevent too much work with forward porting. Reasonable exceptions of 
course allowed ;) (me thinks of a patch of mine for KOdfWriteStore that 
simplifies quite some code).
* Decide that there will be another 2.8 (and 2.9?) as last feature releases of 
Calligra based on Qt4/kdelibs4, so people can keep on rocking Krita and 
perhaps a little the rest of the apps while you do the pioneering in Qt5 land, 
but know that after 2.8/2.9 it is porting-only time.
* Release any releasable result of that branch not as Calligra 3.0, but as a 
separate product, similar to how Coffice is released. Only once all of 
Calligra is ported we can release something called Calligra again.

Hopefully in the time of 2.8/2.9 you have pioneered something that is 
satisfying and stable. That would be then the time of coordinated effort to 
port the whole of Calligra to the new groundwork you did. And perhaps already 
to Qt 5.2 and KF5 (preview), given that time is usually flying.

My 2 (loong) cents

Cheers
Friedrich