Calligra 3.0 for Qt 5.1?

[Friedrich W. H. Kossebau]

Eek, long answers again, sorry, Boud.

Main points:
* 1-2 month is short, community will not be able to come up with that many 
man-days to help, given that it is summer
* completely porting "office core" is already much work to get it really 
right, so better concentrate on that
* 1-2 month are not much time to split the rest of Calligra. just work the 
next 1-2 month on the rest instead of "office core" and things are aligned 
again
* Qt 5.1 is not perfect, less code which gets ported means less trouble to 
match
* Instead of again spending effort on porting XMLGUI, break the tradition and 
try something new
* That initial port does not have to be the final Qt5 solution of the Calligra 
architecture, is just a first prototype. It just needs to be somethings that 
works good enough (and delivers office components). Better architecture can be 
derived from that in future development rounds
* I value interoperation of Qt5/KF5-based apps over supporting people on 
questionable platforms


Below in-text more detailed:


Am Montag, 29. Juli 2013, 21:22:17 schrieb 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.

Sure. But here I wonder about the depth of the impact. And for me this means 
killing as much kdelibs4/KF5 provided features as possible, only because it 
has to be qt5.1, which hurts my interests in Calligra. E.g. I use KIO all day. 
And XMLGUI brings consistency in the UI. Etc.

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

You should have all that with KF5 as well, so far the plan. And with Qt5.2 
even better than with Qt 5.1
(D-Bus or the embedded filedialog might be a problem, right, but the stuff 
which depends on/uses it can be turned into code variants/plugins, so it can 
be still provided on those platform where it is native, like the Gnu/Linux 
ones)

Sure, you cannot have them now and here. But: isn't it quite optimistic to 
have the core libs, some filters and Sheets/Stage/Words completely ported in 
one/two month, Krita + all plugins and then also the rest of Calligra? Are you 
sure Qt5.1 provides everything that is needed? Would such a time constraint 
not rather result in some quick'n'dirty code conversion which will frustrate 
people for a long time with lots of bugs?

I really think that port should be limited to that "core" as Jolla wants it. 
That is already enough work to get it right and good. We do not have a 100 
person developer community with lots of time just waiting to join the effort. 
And it is summer.

After that pioneer port the rest can still be ported. This is 1-2 months, as 
you said. Not really such a large time span to get lost of the rest of 
Calligra.

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

Alright, scripting support seemed to pick up drive, nobody might miss that.

> buggy (karchive, xmlgui shortcut configuration)

And writing our own versions of it will be bug-free and need less time to 
maintain? Let's rather fix it in the proper places, instead of duplicating.

> or deprecated
> since the Qt4 port (kdepim integration).

Here the compiler log is misleading. Most of the kdepim deprecation warnings 
one sees are actually just from headers that are pulled in, while the Calligra 
code is already ported to the new API. 

While Krita may not need integration with KDEPIM, "office" programs surely do 
to become really powerful.

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

Hm, we do not have enough information to decide that without stripping 
everything not-official-Qt?

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

You are not alone with that. But...
... isn't this then the chance to change it? Instead of spending the time/fund 
to port it another time?

Is Jolla really expecting some featurebyfeature-equivalent apps to the 
Qt4/kdelibs4 ones, with all bells&whistles? Or are they also okay with new 
apps if they are based on components that also bring lots of value to their 
platform?

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

I rather would expect the Calligra community to share the long-time goal to go 
to Qt5/KF5.
Who wants to stay Qt4/kdelibs4 in Calligra at the end of 2014? Those who do 
should speak up in this thread :)

And like it happened in the port to Qt4 people will help out the other apps, 
as possible, no?

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

The effort for the other (=non-core) applications surely has to come from the 
community.
The idea here is that you develop some _blue-prints_ with the "core", like you 
have done with Krita for the Calligra-KDE4-era, AFAIK.

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

Then released does not mean packaged instantly, sadly. Also I expect Qt 5.1 to 
have some bugs which will be hit by such a big codebase like Calligra. For 5.2 
there is additionally the chance to get any needed patches in, if something is 
stopping Calligra code. So not sure this argument is on the side of 5.1

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

Agreed. Though that will happen anyway, be it easy or not. Not all apps have 
maintainers/people just waiting to join the porting :( See Kexi, Plan, Karbon, 
etc.

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

That is the concept of pioneers, explore the new ground, setup the 
infrastructure and provide some sample things.

So once things are setup the rest can follow and setup themselves with less 
trouble.

> > 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 am happily a restricted KDE developer :) Though my goal is not only to write 
nice and functional code, but to also use the products as well as make libre 
operating systems more attractive.

He, Krita made a few people turn to Linux! Do not remove that win :) But 
remove them from Windows :)

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

Different people have different motivations, obviously. These goals are 
equally important for me. Otherwise I would work on LO or AOO.

I see the big advantage of KDE in the integration. At least that used to be 
one, these days many apps tend to become more and more self-centric monolithic 
beasts which reimplement lots of stuff, thus making switching between apps a 
pain from the user experience.

Even Calligra itself is missing its opportunities here or at least has not yet 
gone the full distance: think of report generation or database. E.g. Kexi, 
Words, Sheets, Plan could be much more integrated than they are ATM. KoReport 
is a great start, but has yet to break everywhere. Or making a note taking app 
using the brush engine from Krita or support for scribbling on slides, not 
even started.

And then KDEPIM. Plan could so much win from proper integration with a/the 
system addressbook, sadly was disabled to some problem I yet have to 
investigate.

Oh well. That is why I am here. I do not care for Windows. Or OS X. With my 
KDE hat on, that is ;)

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

It's almost complete, already prepared a merge request even :) just found in 
time a small design mistake I yet have to spend a WE on. So would like rather 
to see it in before the port than after. Especially as it simplifies the API a 
lot and reduces the amount of code needed.

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

Sure, do that core. But please only that one, in that porting project.

I am sure you remember the long list of my rather clean-up commits since the 
beginning of this year. Its motivation was to prepare an easy transition to 
Qt5/KF5, because like surely everyone else I am very much looking forward to 
that. But not as a chance to get rid of any kdelibs :( Only to get rid of 
those indirect dependencies that are not used. And for those deps which are 
not really supported on some platforms I would try to find proper 
abstractions, instead of reducing the app's power on my favourite platforms, 
think e.g. of KIO.

Cheers
Friedrich