Calligra 3.0 for Qt 5.1?

[Sven Langkamp]

On Mon, Jul 29, 2013 at 12:11 PM, Boudewijn Rempt <boud at valdyas.org> 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.
>

I have the feeling that we are running into the same problems as we did in
the KDE 4 port. Back then we did start porting too early and that made a
lot more work and to much longer than it should have.

I still excited that Jolla steps up and funds some of the porting work and
with our already stretched manpower we should make use of that.


> 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 prefer the second one. That what be less a surprise for everyone running
master. To avoid much merge work we could put that in feature freeze for
bigger features and at some point merge the qt5 branch back.


> 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.
>
>
Without things like XMLGUI the application is practically unusable and we
would still have to wait for KDE Frameworks. I wonder if we would gain much
if we go the way over the kdefakes library, that might work for the QML
application but on the desktop we most likely have to wait.


> 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!
>
> I'll prepare another mail with a list of technical issues I've encountered.
>
>
> Boud
> ______________________________**_________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/**listinfo/calligra-devel<https://mail.kde.org/mailman/listinfo/calligra-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20130730/e905411a/attachment.htm>