Seeding in spring…
This year, in March 2015, we started the port of Calligra from Qt4/kdelibs4 to Qt5/KF5. Both, because Qt4/kdelibs4 is running out of support and because of the promised lands of better portability and more granular dependencies with Qt5/KF5.
The Qt developers and KF5 developers have done great efforts to ease the porting. Source incompatible changes in the API between both variants were only minimal. And with the KDELibs4Support library a great porting util was provided, which also allowed us to reach some first success in porting after just a few weeks. Only documentation of needed changes could have been better (but we are also used to high standards 🙂 ).
First easy success makes lazy, and with days getting longer and out-door temperatures nicer in the northern hemisphere other things got more interesting as well, so in the following months porting was only slowly progressing. Also were GSoC projects and other feature development done against the stable 2.9 branch during those months, so more porting would have made integrating those things also to the ported version more difficult. Thus we set ourselves the rule to just do as minimal porting as needed, using the KDELibs4Support library whereever possible. Still, a lot of clean-up work based on porting needs was done in the 2.9 branch during that time. And the 2.9 branch got merged weekly to the porting branch, and amazingly this worked without breaking things all the time, just needed minimal adaption here and there.
Harvesting in summer & autumn…
Now, the port will be only really complete once the KDELibs4Support util no longer is needed. The Kexi developers were the first to reach that point, because they followed a separate path in the porting effort, in another branch. The rest of Calligra was still to follow…
Once GSoC came to an end a few weeks ago and with that also any feature development scheduled in parallel, and with no bigger regression known in the minimal porting state, full porting mode was entered: the porting branch became official master branch and since then has seen many commits cutting out the strings to KDELibs4Support. Krita was the first to gain “fully ported” state here, thanks to funded work. Happily, due to the shared code in the Calligra libs and plugins, the rest of Calligra also could win from that funding 🙂
And with further work being done, here we present the next Calligra app that is pure Qt5/KF5-based:
More to come…
The current few regression glitches that sneaked in will be ironed out in the next weeks, along the completion of the port of the other apps. Lot’s to do still, and then also all the existing bugs from before.
But we are dedicated here to make e.g. Calligra Words finally a serious editor for serious documents (and unserious documents, of course), and we get closer than ever IMHO.
So look out for Calligra in 2016!
Attracted by virtual constructs 
Has there been any work done with the VDG regarding the way Calligra Words looks and feels to use? Certainly with earlier versions it felt very different from other word processors which could lead to a roadblock to adoption.
Hi Mike. Getting the VDG in the team is still to come as one of the next steps, for UX (and icons). Currently our focus is completely on porting the existing logic/UI and fixing the core engine, so we have a clean, stable and consistent codebase to work with.
Being different from other word processors though comes for a reason. We do another set of document apps (and components for document apps) here because we want to explore other approaches how to do handling of virtual documents (both for users and developers). Surely will need to be balanced with UX patterns that people have been trained to so far. In any case, a playground that the VDG should like to hang around 🙂 But not there yet, needs a few more weeks.
don’t forget ui tasks need also time to develop.
develop from the vdg maybe some user surveys, discussions, mockups, …
hi
since now there was no cooperation with vdg but as we have Heiko how is working in the libreoffice ui theam it would be a big benefit for calligra. in addition I should have a look about the missing breeze icon. where is the kf5 port?
Hi. Thanks for the offer with the missing breeze icons. I can generate you a list of the missing icons, as we have tagged all icon id strings in the code, so they can be automatically extracted and mapped against the iconset (see file KoIcon.h in the toplevel folder). Will do that tonight and send you the list as start, so we can put it whereever you organize the icon creation.
The qt5/kf5 code is in the master branch.
what id love is for a way to reuse document export libraries in other projects and or other platforms.
Hi Glenford. Yes, reuse is part of Calligra goals. Both reuse of Calligra components/libraries and reuse by Calligra of existing components/libraries.
The Calligra export logic is not yet shaped for simple separate use, but note taken.
Then there is the Document Liberation Project (https://www.documentliberation.org/) as a start for collaboration on import filters at least. Not sure though the project will feature a lot of code to write to proprietary formats, as it conflicts with its goals (to which I agree).
ATM Calligra is rather a happy user of the libs from DLP for a few formats, hopefully also Calligra devs will contribute in the future to that project. And if only by sharing specs and format analysis tools.
[…] Calligra Words 3 Alpha: now pure Qt5/KF5 […]
This is cool stuff but I did want to question on of your statements: “But we are dedicated here to make e.g. Calligra Words finally a serious editor for serious documents (and unserious documents, of course)”
In the past this has been an issue with Calligra Words, no document backgrounds, etc. Unserious or serious documents often have backgrounds, cheesy homemade certificates and what not.
In the past commenting about such missing features received pushback from the team akin to, “That not really word-processing”. Well for a lot of coaches, grandmas, etc… that is about as hardcore as word-processing gets. It just seems like Calligra Words isolated many low end users that could benefit from a simple word processor.
Rob.
«Calligra Words finally a serious editor»
May the gods listen to you… And we can finally open documents made with Lobreoffice and see how Words open them correctly, respecting the format, footnotes, and such.
Let’s hope it’s a reality and not only a good willed intention when Calligra 3 is published.
As always, thanks for your hard work anyway.
[…] Calligra Words 3 Alpha: now pure Qt5/KF5 […]
[…] today, one of the Calligra developers brags about the fact that the Calligra Words component of the open-source office suite has been fully […]
The GUI is nice and flat except from the “close” button and the two square “…”-buttons? Why is that? I have seen this elsewhere in other KDE apps as well.
The default widget theme in KDE is Breeze, which looks like that.
Personally, I rather like it.
[…] this week we could report that Calligra Words 3 has joined the club of pure Qt5/KF5 apps, now we can say the same about Calligra Stage 3 […]
Will this second port of Calligra on QT5 allow to get a full Calligra version working on SailFish OS 2.0 ?
Or at variance, would it remain a lot of work in order to get a Calligra Mobile version working on current Jolla Phone ???
Hi JollaUser. I assume with “full Calligra” you mean not just viewing components as used for the official SFOS Documents app, but instead editor apps for e.g. text documents, slides & spreadsheets. If so, then there are two, three things waiting to be done:
1. get proper UI version of the editor apps for touch input devices done
2. get SFOS to use more recent Qt, e.g. 5.5, as Calligra code and the used KF5 libs need more than Qt 5.2/SFOS has.
3. port away Calligra Sheets from kdelibs4support porting util lib, which currently is blocked due to QLocale not having all things needed.
Personally I would like to see Calligra-based editors on SFOS ASAP 🙂 But it needs a lot of work still. We are not even there yet to update the SFOS Documents app from the old forked Calligra libs to the current Calligra libs, due to points 2. and 3. 😦 At least I have already been able to setup a build of the current SFOS Documents app locally, so if those points are history one day, I should be able to more quickly work on updating it.
Hi Finring !
Thanks for your answer.
The part in TogetherJolla gave few answer to your post (That I put there in order to wake up the discussion) :
“I’m afraid that his point 2., namely, upgrading SFOS Qt libs to at least 5.5, won’t happen in a near future… This is the main blocker IMHO, and the community cannot really help for this. Then, since the document app is open source, it will be quite strait forward to upgrade to latest Calligra and hopefully design a specific UI for edition.
Maybe when the ramble from November 15 settles down a bit, one could add in the IRC community meetings the following question : « plan or roadmap for Qt 5.5 in SFOS, and how the community can help (tests, bug triage in Mer…) ? »
Damien Caliste (Jan 19 ’16)”
https://together.jolla.com/question/65413/port-calligra-gemini-to-sailfishos-as-native-office-suite/
With the not yet envisionned evolution to Qt5.5, would it get some ressource in your environmet (aka “calligra developpers”) to provide a mobile version based on Qt 5.2, thus affordable for SF.OS ?
Or at least, would the work easier to do (as there is a directory “calligra mobile” on the Calligra’s site) ???
Best regards
Jolla User