Calligra 3.0 for Qt 5.1?

[Boudewijn Rempt]

On Monday 29 July 2013 Jul 19:07:45 Friedrich W. H. Kossebau wrote:
> 
> But: having this influence how Calligra is ported to Qt5/KF5 reduces my 
> happiness. 

Well, sorry, but that is unrealistic. Of course it will influence how Calligra is ported. You cannot gain contributions without being influenced by them.

> 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. 

And make the OSX port finally not suck. And make Android ports that aren't a hack possible. And yes, I want those Windows users, too. They are important.

> 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.

I don't want to keep 100% of the KDE features we have now... Many of those features are only half-implemented (dbus api), barely maintained (kross scripting), buggy (karchive, xmlgui shortcut configuration) or deprecated since the Qt4 port (kdepim integration). One reason why I actually look forward to stripping down to a minimal set of dependencies, ideally not much more than Qt, is that it will give us a chance to make an informed decision on whether it is worth it to depend on e.g. kio for the functionality it brings us.

> 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? 

No: the xmlgui qwidget based apps are irrelevant for Jolla. Only because of our old 1990's era architecture, we will have to drag that into the port, so there are hidden XMLGuiClient-based classes all over any QML-based calligra application... I really want to change that.

I would like the community to work on the port as well, make sure that the other parts of Calligra don't fall behind. My big fear is that we'll see another fork: a Calligra based on Qt5 that has words, stage, sheets and Krita, and a Calligra based on Qt4 and that the project will tear apart.

> 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?

But that's just not realistic. The effort to come to a really nice separation into components will have to come from the community -- because refactoring Calligra is really hard. You cannot expect any organization to fund work going on in Karbon or Plan or so, just because those apps build on the Calligra libraries and need to be dragged along when refactoring, when those apps are barely maintained and, in effect, irrelevant for those organizations.

> It takes some effort to switch the devel environment to Qt5/KF5, 

That's why I think that sticking to a released version of Qt -- that is, 5.1 -- is important. Otherwise setting up a devel environment is really hard. Setting up a KF5 devel environment and maintaining it is already no fun at all.

> learning all 
> the new things and fighting any problems of that young version. Do you think 
> everyone can follow instantly?

No -- I don't think so. However, we should make _easy_ to help out in the Qt5 porting effort. Because otherwise, parts of Calligra will be left behind.

> And should master not be the always-releasable branch?

Yes, that's the argument Dmitry also makes, and it's a good argument.

> 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.

Hey, my first mail on the subject was in April! And what I'm saying here is not materially different in any way. And I also didn't want to bring the subject up again before we knew that there would be funding, either. And yes, now everything is in a hurry. And it's not a huge amount of funding, so it's important to spend the time it buys us well. It would be a big waste if the effort didn't benefit Calligra as a whole.

> 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.

Making using KF5 a goal in itself makes sense, but only from a restricted KDE developer's point of view, where the goal of a project is to write nice code. I don't want to restrict myself to that. I want users for Calligra, millions of users. I think we should write software with that goal in mind -- the goal of Calligra should be not to advance KF5, or be useful to the whole of KDE software, but be useful and attractive to users.

> 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).

In that case, I would say: stop refactoring in master. A code simplication for KOOdfWriteStore can be a nice thing, but it's not something any user of Calligra is waiting for. If you want to refactor and clean up and simplify code, do it in the Qt5 branch, not in master.

For master, keep to features that users want and to bug fixes.
 
> * 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.

I really, really am afraid that that will mean the end of the rest of Calligra. That the codebases diverge enough that the applications that didn't make the transition basically cannot be ported anymore using community resources.

> 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.

We have to have a working Qt5.1 based Calligra core (libs, words, stage, sheets) in a month or two. That's the timeframe I'm looking at... KF5 won't be ready until 2014.

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