As I posted the last time I blogged (which I really should do more often), I had some problems with Calligra Active on Android and the number of shared libraries it requires (various versions of android have different, but low, fixed maximums for the number of .so files that can be loaded in a single process). Since then I did several things to resolve that. One option would have been to go the "libkok" route, like we did when we developed/ported calligra/koffice to Maemo and the Nokia N900 and N9. There we basically rewrote the kdelibs cmake files to just build those files that we really need, and build it all into one big library. The big problem was that approach was that it was completely unmaintainable, which meant that we were basically stuck with whatever snapshot kdelibs version we chose to base that on. So instead of doing that I got out the CMake manual, and came up with some relatively simple cmake code that basically combines several existing targets into one new target. The downside to this is that it still has to build all the individual targets as well, so build times basically doubled, but other than that it gives me a nice "libkall.so" that contains all of kdelibs that Calligra Active depends on, combining 11 .so files into one. See here if you're interested in the CMake code I came up with. I did something similar for the libraries Calligra itself provides reducing the number of .so files even more.
(I had some problems to combine the various kdelibs libraries together because of the way automoc works. Basically when you have several source files with the same filename but different directores they will overwrite eachothers .moc file if they are built in the same target. To get around that I renamed some files).

Besides libraries, plugins are another major contributor to the number of .so files. Combining these is a lot harder though since plugin entry points and things like that result in lots of symbol clashes. So instead of trying to work around that, for now I decided to just not include several sets of plugins that are not strictly necesary. In this case that means not including any filters (and thus my current Calligra Active build is limited to odf files, but then most filters didn't seem to quite work correctly yet anyway), and also not including the various spreadsheet function plugins. Most spreadsheet applications store the result of calculations in their ods files as well as the formula, so instead of recalculating everything we can just show those values.

So with that out of the way, I now have a version of Calligra Active for Android that should work on any android device with android version 2.2 and newer. However I only have a device with android 4.x, so for testing older versions I have used the emulator. I have managed to successfully run this version in a 2.2 emulator, however on actual devices running that version there unfortunately seems to be a problem while loading the combined kdelibs .so, giving a very unhelpfull dlopen error (dlopen on android 2.2 seems to only be capable of returning "file not found" regardless of what the actual linking problem was).

I invite people to try it out anyway. You can find my latest build at heap.kogmbh.net/mek/CalligraActive-debug.apk. There are a couple of issues with this that I'm already aware of. For one, Calligr Active was never designed with phone form factors in mind, therefore the entire UI doesn't really work/scale very well to these kinds of screen/resolutions. Secondly the 3 big buttons on the home screen currently don't do anything, since they depend on some kind of metadata/nepomuk/soprano like system afaik, which does not exist on Android, so currently I commented out all bits of qml that do anything for that (I probably should have also commented out the actual buttons). Also startup (especially the first time after installing) is very very slow. The first time you start Calligra Active it will unzip several megabytes of icons/plasma themes/other misc files, but also other startup code is pretty slow. When it actually has started performance should be pretty good (at least I hope, I've never tested it on less powerfull hardware).
(sorry for the big wall of text)

Yesterday nokia gave away 300 pre-production n900 devices to all attendants of this years Maemo summit in Amsterdam (in the form of a six months loan, after that they'll have to go back to Nokia). I'm also attending, so I also got one. Deciding what the first thing to port to a new device is is always hard, but in the end I figured that something with plasma might be nice. As maemo5 makes it possible for home-screen widgets to be part of separate processes, I figured it might be possible to adapt plasmoidviewer to act as a simple program to put any type of plasma applet on the normal maemo desktop (actually, I think it was somebody else that suggested this, I just don't remember who it was). So after several hours of hacking (and a lot more hours of compiling Qt and various parts of kde (btw, the just released Qt 4.6 maemo5 technology preview is missing some essential bits like for example qdbuscpp2xml), I managed to figure out just exactly how to get the window to appear on the normal desktop as a widget. At first this didn't look to pretty as you can see in this screenshot:

But after several more hours of hacking and trying to figure out how transparency works in X11, I even managed to get nice translucent applets. Also I figured out how to hook up the normal maemo5 widget configuration system to display the correct configuration dialog when you click on the configure button on one of these plasmoids. So with in the end maybe 20 lines of code, I got a rather good working implementation that makes it basically possible to have any plasmoid you might have on your normal kde desktop, also on your maemo5 home screen. One (somewhat major) problem with the current implementation is that it is not possible to resize widgets, but as far as I can tell that is mostly a limitation of the maemo5 desktop widget system, so I'm not sure if there is anything I can do about it from my side.

After quite a while of not doing much maemo related, I finally found the time to build a bit more up-to-date kde packages for maemo. I've now uploaded kdelibs, kdepimlibs and kdebase from KDE 4.2.0 (more modules will follow), and also the just released koffice 2.0beta6 (unfortunately no kspread yet, as I couldn't get it to compile with the old gcc version in scratchbox). If you want to play with kde and/or koffice on your maemo powered device, add the following line to your /etc/apt/sources.list:deb http://93.157.1.37/~marijn/maemo binary/, and install kde and/or koffice related packages (you probably don't want to install them to the small rootfs, as the packages are still a bit big). The state of maemo/hildon integration for kde applications hasn't changed much since my previous packages (for example applications still don't have a correct icon in the taskbar), but I hope to be able to spend some time in that area as well.
I'll also be at fosdem this weekend, so if anyone has problems getting the packages to work, you could try to find me there :)

Until now I've always been using my own built Qt packages when building KDE packages for maemo. Initially because the Qt packages in extras-devel where missing some vital parts for KDE (mainly SSL support I think) but after that because I just had them installed, and it worked. But now I wanted to change this, and use the extras-devel provided Qt, as in theory that shouldn't matter, after all they are build from the same sources, with nearly identical configuration. As it turned out, this was actually quite a bit harder than I thought it would be.

As turns out, the current Qt packages are built with vfp support (which is a good thing, as it should make floating point computations quite a bit faster), but the default qemu version being used in scratchbox does not support vfp. Fortunately scratchbox also includes a newer 'cvs-m' version of qemu, that does support vfp, so I though I'd just use that instead. However that provided another unpleasant surprise, namely cmake doesn't work (correctly) in that version of qemu. I'm not sure what the exact problem is, but in some cases cmake failed to generate some files either during configuration or installation of a project.

One possible solution I first tried is to use the 0.8.2 qemu for running cmake and the csv-m version for running everything else. The difficulty with that approach is that you somehow have to make cmake (which is run in one version of qemu) run sub-processes that are run in a different version of qemu. As you might imagine, that didn't really work out as well as I hoped. So I was back to trying to find a version of qemu that is both capable of running cmake and vfp enabled applications. I first tried a 0.9.2 version I got from Jonas Hurrelmann, but that version didn't work either.

Jonas than suggested I tried compiling a newer svn version of qemu from qemu-arm-eabi.wiki.sourceforge.net. With that version of qemu I finally managed to get both a functioning cmake and function vfp/qt-tools. This isn't the end of this story though, as with this qemu version at unpredictable times automoc will just stop responding. While this isn't a very big problem to manually build stuff (you can just restart the build and continue where it failed when it hangs), it is quite anoying when trying to automatically build kde packages, as it is very hard to automatically detect qemu/automoc no longer making any progress; so for now I'm mostly back to manually building stuff... One possible solution would be to not use qemu, but use sbrsh and run the ARM binaries on a real ARM processor, although I fear that might make building stuff quite a lot slower.

And since a blog post without screenshots is boring, here some screenshots to close this post with:

As KOffice is supposed to be a lightweight office suite, I figured it would be nice to see how well it would run on maemo based devices. Thanks to Thomas Zander who replaced a lot of the double usage in koffice with qreals it was quite straightforward to get koffice to compile and packaged. Well, for the most part that is, I didn't manage to get kspread to link as apparently the old gcc version I'm using has some problems with inner classes in templated classes and duplicate symbols. After fixing some trivial issues, I could install koffice on maemo and run it:

As you see in these screenshots there are some clear user-interface problems; the dockers use way too much space for such a small screen, and somehow the toolbar is at the bottom instead of the top of the window (I have seen this earlier also with for example konqueror, so perhaps there is some general kde/qt mainwindow bug on maemo, but I haven't looked into that any further). So while the UI is far from suitable for these devices, drawing stuff with karbon actually works remarkably well. I think it is very realistic to create a slimmed-down UI for koffice applications to make a very usable office suite for maemo using a lot of the existing koffice code.

If anyone else want to try running koffice, maemo package are available in my repository.