Selecting text in the Calligra-powered Okular plugin for ODT, DOC, DOCX & WPD

Traveling 8+ hours on the train all the way through Germany to Geneva in Switzerland, where CERN is located (its area spreading across the border to France actually), the place of the WikiToLearn-Plasma-VDG-TechbaseOverhaul meeting, was also a good chance to first spend some time again on a sprint-unrelated, but still KDE-related item, which is adding support for text selection to the Calligra-powered Okular plugin for text documents.

With some first satisfying prototyping results, where selection highlight is rendered at the correct positions and the correct chars being copied:

Polishing this up is left for the trip back home on Sunday. Looks promising so far, you hopefully soon will be able to select text from your DOCX, DOC, WPD and ODT files you view in Okular using the plugins from Calligra (once both Okular based on KF5/Qt5 and Calligra 3.0 are released, TBD).

One thing learned on the train: forcing your SchuKo-style power plug into the Swiss train’s on-board Swiss-style power socket might work (SchuKo connectors have a slightly bigger diameter), yes.
But: it takes some time to get it out again, without destroying the socket, so it is best started to be done some time before the switch-trains-here station is reached, not only a few seconds, which has one run the risk of not getting out in time. Or having to leave the power supply behind, better to be avoided as well 🙂

New Year Calligra Words Sprint

When the streets are covered with snow and ice in many parts of Europe, it’s a good time to sit inside in front of our computers and to improve that software we are sharing here with each other.
With the porting of the apps, plugins & libs part of Calligra to Qt5/KF5 roughly done towards the end of 2015, it is now also a good time to work on features again.

Given a few Calligra developers interested in improving the text-handling modules, we looked into doing a developer meeting (a.k.a. “sprint”) on that quickly, and given January being a good candidate for snow and ice on the streets, we scheduled it for the 4th week-end of January, so the one that just passed.
In the end it was just three of us who could make it, but small can be also better 🙂

A big share of time of the sprint was invested into spreading knowledge about the current text-layout system by its architect Camilla, by explaining and discussing the current design and code.
To apply, test and enhance the learned things about the layout system, we started to draft and to implement support for the concept of text sections (as in OpenDocument Format’s <text:section>) to the system.

While talking about the text-layout system and the data structures, we also looked into the Calligra plugins for the document viewer Okular (learn more about the plugins). We checked and fixed a little the current calculation of the positions of headings for the table of contents. And drafted how to use the layout structure data for the calculation of characters positions on a given page, to finally implement support for text selections and hyperlinks with the plugins.

And with OpenDocument Format engaged people around, we also chatted about ODF-related things a little. E.g. that having a central database where all errors & artifacts injected into ODF files by the known ODF producer software is collected. Because with some N-number of ODF producer software all M-number of ODF consumer software need to each write support for possibly dealing with broken files from all N ODF producer software, and need to know what to care for and how. It might be nice to perhaps just have a single broken-ODF-file-fixup software one could use, so one’s ODF consumer software can simply expect sane ODF files.
While mentioning ODF here: consider visiting Jos’ talks at FOSDEM upcoming week-end, “The Future of OpenDocument (ODF)” and “Eternal Plugfest”.

It happened that due to a date mixup the Krita developer community did a small sprint at the same place at the same time. Which worked out nicely not only for the social parts of the sprint, which we all did together. Also during the working times often we were sitting mixed in the same rooms.
It was also an occasion to learn more about Krita’s OpenGL-based rendering, which could be an inspiration for a new generation of Calligra’s shape rendering system (which I personally am thinking about).

These are the sheets with explanations that I take home with me, next to the digital and mental notes:

(One day hopefully we finally will do such sketches not on real paper, but on virtual sheets, using Calligra + Krita modules :)) ).

It was a very productive and enjoyable week-end, in a wonderful atmosphere, I am happy we did this meeting.

Thanks a lot to Boudewijn and Irina for being the great hosts to our Calligra Words sprint and for giving us the free accomodation in their home, incl. breakfast, drinks and more, in a family-like way.

This sprint was also enabled by the supporters of KDE e.V., thanks to them to make it financially possible for us Calligra developers to meet up for face2face talking and working.
If you, dear reader, want to do your little contribution to the future of KDE software as well, consider to Join The Game as a supporter of KDE via the KDE e.V. !

Your input, please: naming of action icons (tables, vectorpaths, animation, text, …)

Developing an application where you use or need icons for actions around tables, vectorpaths, animations, text formatting? Looking forward to use Breeze-styled icons, shared with other applications? Then please read on, this is especially for you:

The Breeze iconset currently gets further icons, as needed by the different Calligra apps and plugins. And that are many icons.

Given these icons are then in the public namespace (without any Calligra-specific prefix) and ideally also can be reused by any apps, we need to ensure there are no icon name collisions and also that semantics in the naming are properly done. The XDG Icon Naming Specification currently is leaving a lot of room and surely one day can also get more feedback by the names we start to use here.

Please have a look at the overview of proposed icon names:
https://community.kde.org/Calligra/Icons/3.0
(shows also old custom icons used in Calligra and old custom names).

And then please tell (e.g. by commenting on this post or by replying to the email on ML kde-devel ) where you see chances for improvements. The quicker you comment, the better, because this is WIP and might soon create facts.

While there are naming proposals already for most icons, there are a few in need for any naming proposal at all. So listing them here explicitely once again (see details in the overview page):

• borderpainter
• black
• highlight
• special_paste

Andreas from the VDG has already started to do and commit first such icons in Breeze style to the repo of Breeze icons, see links below to get an idea what is coming up.
There have been done already quite some Breeze-style icons for LibreOffice. Just, LibreOffice for legacy reason has their own internal icon naming and resource system, so the Breeze icons as created for LibreOffice are not in the normal Breeze iconset and not following the XDG Icon Naming Specification. But by that there is some iconic language existing and SVG code to reuse. Still, this is a big amount of work to be done, so we Calligra developers are very happy that Andreas has started to tackle this!

Initial commits:
Calligra escape directions
Calligra connection line types
Calligra path editing related icons
Calligra Borders for multiple cells icons
Adde dmissing action icons to icons-dark

PS: Anyone a good idea how to embed external SVG files in Community Wiki pages? Using link as plain text only works with PNG files (and once the url ends with “.png”), but not SVG ones.

Karbon 3 Alpha: also pure Qt5/KF5 now

On the road to a Calligra with no more need of the porting util KDELibs4Support another milestone has been passed: Karbon now also is based purely on Qt5 and KF5.

As with the other ported Calligra apps, some small glitches here and there and then the old bugs. Well, work in progress 🙂

You might have discovered on the screenshot that the Stencil box is shown, which in Calligra versions 2.x and before was exclusive to Calligra Flow. Adding stencils for flow diagrams and other things can be also useful in presentations or text documents, so the Stencil box will be made generally available in Calligra 3. It still needs to be thought about how to perhaps merge it with the general Shape box, that is left for later for now and surely something to work on with the VDG.
Calligra Flow itself has not seen any porting efforts so far, as the plan is to rewrite it using Karbon components, given that Calligra Flow handles the same document type as Karbon, rich vector graphic documents. The main difference has been that Karbon only supports single-page documents, while Calligra Flow also supports multiple pages. And both UIs have been targetting different use cases.
The idea and goal here is the same as with e.g. Calligra Words and Calligra Author: reusing components while providing optimized UI for the different usecases.

For now though we are still in the porting phase: get rid of “KDELibs4Support” completely, fix any regressions and then some bugs, also get all unit tests to pass again. So no dreaming about future features yet, first we need a real base for that.
There are still 21 matches in 16 CMakeLists.txt files on “KDELibs4Support” in Calligra’s codebase, sigh… Calligra Sheets, Calligra Plan and Calligra Gemini are still awaiting their final port. So time to get back to the KDevelop window… 😉

Calligra Stage 3 Alpha: next pure Qt5/KF5 one

Earlier 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 Alpha:

As with Words and the other Calligra apps, Stage of course has seen a few regressions due to the porting, which will be need to be ironed out in the next phase, together with the existing old bugs. Where you are invited to join our efforts!

And quite some code still left which depends on the util KDELibs4Support library (47 matches in all Calligra CMakeLists.txt files). So expect some more success reports about porting away from it 😉

In other pure-ness news, we made a decision that was hard to do, but which seems most pragmatic and which has now also reached a milestone: Krita has been split off into a git repository of its own, on its way to become a project pure on its own, outside Calligra.
git clone git://anongit.kde.org/krita
is how you can get Krita code now. The “master” branch of Calligra contains no more Krita code since a few days already. The current 2.9 version will still be maintained and released from the Calligra repo as part of Calligra 2.9, only Krita 3.0 will be the first on its own, and Calligra 3.0 the first without Krita.

This was not done lightheartedly, after all the years in which Krita and the other Calligra apps have been developed together, sharing the same libraries and many plugins and gaining a lot by the resulting synergy. Now with the success of Krita many new developers have joined its development, which is great by itself. Just, most of them are interested in a painting app, but less or not in the other Calligra apps or the abstract middleware for document-content apps, as there is with the Calligra libs. Also with more developers now hacking on Krita only than the rest of Calligra together, enhancing the Calligra libs together was often not possible due to missing time by the other app maintainers, which resulted in more and more Krita-side-only additions to the shared libs. Which made things a lot more complicated for everyone, outweighing any synergy.

All the libs and plugins shared so far have been forked by Krita and are being reduced now to the max. We already made sure Krita 3 and Calligra 3 apps can be nicely co-installed without clashes. We could also see a last synergy: all the Qt5/KF5 porting work on the shared code was done when it was still shared 🙂
Will be a hard time for developers working on both projects in the beginning due to a lot of code being similar, but no longer the same, but we will manage.

For me this means also that a feature I had on my TODO list will be harder to achieve, with all the brush-engine code from Krita no longer inside the Calligra repo: supporting sketching and scribbling in all kind of documents by pen input, using the great brushes from Krita for better looking strokes etc. But well, I first have to get to this entry in my long TODO list anyway before I think more about it 😉

Calligra Words 3 Alpha: now pure Qt5/KF5

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!

Calligra’s 2nd port to Qt5 & KF5 slowly progressing

There is a lot of nice stuff to do in northern hemisphere currently, given it is Summer time here. And porting is less nice to do, so many problems to solve with no immediate gain usually 🙂
Thus things are moving slowly in the on-going port of Calligra to Qt5/KF5 (cmp. first success at begin of April).

But they are moving, at least.

A few libraries have been split off from Calligra into own repos (more on that in another post), and one is around report generation. This week Calliga Plan, the project management application, could be made working with it again, here a preview (reports not yet added to build in the “frameworks” branch, still waiting for API of the now external library to become stable):

The busy bees behind Krita, the sketching and painting application, all currently are still buzzing around improving the Qt4/kdelibs4 version in the “calligra/2.9” branch, with new features on a sometimes daily basis 🙂 To not lose any improvements there while at the same time the port is going on, currently the policy is that only changes as minimal as needed should be done in the “frameworks” branch, where the port to Qt5/KF5 is happening, to allow simple merging of the “calligra/2.9” branch. The merges are done roughly on a weekly basis, and so far no complicated or unsolvable conflicts were met, also thanks to Qt5 & KF5 with kdelibs4support offering good source compatibility (and what is perfect 😉 ).
Surely this cannot go on forever. Once all regressions in the “frameworks” branch compared to the “calligra/2.9” branch are as good as fixed (with the currently ported programs, some might be lost due to lack of maintainers), this will be declared a milestone: developer focus will switch and feature development then will happen in the “frameworks” branch, which then also might already have become “master”. Not yet completely decided on. And after that we should soon see finally the first released version of Calligra based on Qt5 & KF5.
(BTW, Kexi, the visual database applications creator, has gone for a different porting story, porting directly to kdelibs4support-free code, thus sadly currently only in a branch separate from the “frameworks” branch, until the milestone mentioned before will be reached).

Still now and then a few things are done also for the port of Krita. And on a first glance (if having turned off OpenGL usage), things start to look promising:

So, still not there, still a lot to do, but slowly getting somewhere 🙂 And as usual you are invited to join the efforts.

Like Braindump? Adopt it for the Qt5/KF5 port!

As you might know, Calligra now also started porting to Qt5/KF5. We are currently reaching the end of stage 1, where everything is readded to the build (“links and installs? done!”), with next stage then to fix anything that broke or regressed (see screenshots!1!).

Just, we also now see that noone in the current set of active Calligra developers has enough love left for Braindump, the notetaking and mindmapping application from the creativity and productivity suite Calligra.

So as it stands Braindump would be left behind during the porting phase and be discontinued, for now at least 😦

Braindump is a nice example for the flexibility of the Calligra architecture, where objects are implemented by so called “Shape” plugins, which then are available to any application supporting “Shape”s in general. The actual code of Braindump itself is centered around the concept of whiteboards with unlimited canvas, where one can drop all possible kind of objects (the “shapes”) and then note their relations. With automated saving in the background, no need for any “Save” button.

See this older video to get an idea of the possibilities:

Cyrille, who has developed Braindump, says:

“I am still interested in the application itself, but what it really needs is a better user interaction, and flake [name of the Shape system, ed.] is not flexible enough to provide it, and I don’t have the energy to make it flexible enough”.

He and the rest of the Calligra team will happily assist someone who ideally already uses Braindump and now would like to overtake the future development for the Qt5/KF5 based version, to enhance their workhorse. And the porting time is a good time to get to know the current system: for the first Qt5/KF5 based Calligra release, 3.0, we are concentrating on a pure port, so no new features or refactoring (ignore the exceptions 😉 ), only minimal changes. And envisions the options after the port/3.0: e.g. get Braindump to run on your Android or Sailfish OS tablet! Connect it to syncing servers like ownCloud! Or whatever would enhance your Braindump usage.
And all done while enjoying the synergy effects from the shared libs and plugins of the Calligra suite.

Your chance, now 🙂 Don’t hesitate too long, as Braindump will bitrot more and more, once the 3.0 release is done and the Calligra libs will see more refactoring.

Find us in the channel #calligra on irc.freenode.net, or join the mailing-list calligra-devel@kde.org.

One year old: Document Liberation Project

On the list of projects-I-would-like-to-contribute-to-but-no-time-yet it is one of the top ones: the Document Liberation Project. There are quite some files from old times on my storage devices whose content is locked away in binary blobs that act like safes whose keys got lost with the software that created the files. So it’s easy to guess how I feel towards such initiatives, allowing me to regain access to my very own data 🙂

The Document Liberation Project only was founded last year officially and now can see at least it’s first birthday. Not yet picked up much steam from new contributors so far, but then already serving e.g. users of Calligra, with libraries like LibRevenge, LibOdfGen, LibWpd, LibWpg, LibWps, LibVisio, LibEtonyek etc., to read in data from files in WordPerfect, MS Works, MS Visio, and Keynote formats.

Once the port of Calligra to Qt5/KF5 and thus version 3.0 is done, I hope to finally pick up the work (see here and here) on being able to read my old Corel Draw v4 files with Karbon or Flow. Which these days surely means using LibCDR from the Document Liberation Project, instead of my own custom code. Perhaps I will then also be able to contribute a little to the project finally 🙂

While talking about that, another related thing still waiting for implementation is extending the hex editor Okteta to support the binary format grammar that I developed during the writing of my CDR import code, so Okteta’s Structures tool would be able to read in the grammar and then show the content structure. Or a combination of that grammar and the one used by msoscheme, which is used for some of Calligra’s MS format import filters, which I learned about in the meantime.
Having a standardized grammar for binary formats, which can be both used by data inspection tools like hex editors, but also for code generation, surely will be good to have. There are already some related tools also created/used by the Document Liberation Project, something to look at for more synergy effects.

Hm, filled TODO lists, but winter time with it’s long nights is over now. Too bad.

First success in Calligra’s 2nd port to Qt5 & KF5

Last month, in March, with the 2.9.0 release done, we Calligra developers followed our plans and started a branch named “frameworks”, to work on version 3.0, to be the first version based on Qt5 and KDE Frameworks 5. Calligra 3.0 should not see any new features, the focus is purely on getting the port to the new platform done without any regressions.

In a first phase we are currently trying to readd any libs, apps and plugins back to the build, adding TODOs for the second phase where simple changes are not enough.

A week ago finally we managed to get the first apps to start, e.g. Stage, Words and Sheets (somehow Oxygen icons still sneak into the UI for me):

A few things are still left to be added back to the build, before the next phase can be entered, where anything broken will be fixed. Some things are even already nicely working, e.g. the Calligra ODT plugin for Okular together with the Calligra DOC import filter make the (WIP and not yet released) Qt5/KF5-based Okular show a DOC sample file, like before with the Qt4-based versions:

“2nd port”, you might wonder? It happened that (some part of) Calligra was already once ported to Qt5, in 2013, to power the Documents app on the Jolla phone. Just it also happened to be unlucky timing, as the KF5 were only starting to exist, also was the Sailfish OS still at Qt 5.1 at that time, while KF5 was needing at least Qt 5.2. So that first port ended up as a dead branch. Still, some experiences made during the port had influence on changes to the Qt4 branches, and even a few of the old commits could be now cherry-picked and applied unchanged to the “frameworks” branch 🙂

No idea when Calligra 3.0 is good to be released. It’s done when it is done. We will work hard to make it done this year. In Q2 would be nice. In Q3 might be more realistic. Now, join the fun 🙂