[prev in list] [next in list] [prev in thread] [next in thread] 

List:       calligra-devel
Subject:    Re: Calligra 3.0 for Qt 5.1?
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2013-07-29 19:22:17
Message-ID: 3988338.kZ4IAYQCpI () linux-ixka ! site
[Download RAW message or body]

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

_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


[prev in list] [next in list] [prev in thread] [next in thread]