Calligra Active on Android

As I wrote in my previous blog post, I've been doing work on getting Calligra working on Android. My first attempts of this used Calligra Mobile, our QWidget based mobile UI originally written for the Nokia N900. One big problem with this is that the scrolling speed when running on android was horribly slow. I think I got maybe 1 or 2 frames per second, and that on fairly powerful hardware. Early on in the development process of the calligra based document viewer for the Nokia N9 we were having similar performance problems, caused by wrapping our QWidget based canvasses in a QGraphicsProxyWidget. Now Calligra Mobile itself is completely QWidget based, so it shouldn't have those problems (it works decently on the N900 afterall), but because of the way Qt on Android is implemented there is a similar kind of indirection going on as with QGraphicsProxyWidget, so instead of trying to fix the performance of Calligra Mobile, I decided to instead give one of the other mobile UI's of Calligra a try.

So since my last blog post I have managed to get Calligra Active, a QML based UI, ported to android. With a QML based UI, backed by an OpenGL-ES viewport this results in much much smoother scrolling (at least on that hardware I'm testing on, I haven't managed to try it on older hardware yet because of certain problems). Getting Calligra Active to work also required me to get some more bits of KDE Libs and KDE Runtime ported, since Calligra Active uses various Plasma Qt Components for its QML UI. For a real android UI it probably makes more sense to use a different set of Qt Components that try to mimic the android look and feel instead of trying to look like plasma, but it is still nice to know that it is possible to use something like the plasma components even on platforms like android.

Then about my problems getting my current Calligra Active build to run on older android devices. As some of you might know, android's dynamic linker has a hard-coded limit on the number of .so files (shared libraries and/or plugins) you can load in a single process. The limit on older android versions is 64 (on newer versions it got increased to 96 and later 128), and as it turns out, because of the highly modular nature of calligra (and much of kde), I was pretty close to the 64 limit with my previous non-qml based UI attempt, and adding libplasma, its dependencies as well as the various qml plugins needed by Plasma's Qt Components apparently pushed me over the limit. So for now it is only possible to try to play with this on devices running Android 3.x or newer.

I'm not sure yet how to best get around the limit of 64 .so files. Some obvious ways are trying to adjust the calligra build system to for example have one big plugin for all spreadsheet functions instead like it is now to have 18 different ones for different sets of functions, but I think I'm hitting the limit already before it even gets to trying to load those plugins, so it seems likely I'll also have to actually combine some of the many libraries I'm using from both kdelibs and calligra. So although for completely different reasons this might end up being sort of a repeat of the libkok mess that I was trying to avoid (libkok is the name we gave for our one library containing all of kdelibs that calligra on the N900 and N9 requires). One big difference between that libkok and what I might end up now though would be that I have no intention of actually removing code that calligra doesn't need, instead I'm trying to come up with the least intrusive/most maintainable way of building the entire set of kde libraries into one .so (if only it would be possible to just combine several .so files into one after they are built, but I don't think that is possible).

So anyway, if you have an android 3.x or 4.x device and want to try if Calligra Active works for you, you can find the .apk file here. Startup time of it is still pretty bad, since it does a lot of work that is not necesary as well as having a lot of debug output enabled, but other than that it should hopefully work, I've at least tested it to load .odt and .ods files, I'm not sure if other file formats work in this build.