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. _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
